<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 05:57:29 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[SERVER-63322] Reading between commit_timestamp and durable_timestamp can produce inconsistency </title>
                <link>https://jira.mongodb.org/browse/SERVER-63322</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;There is a problem with prepared transactions whose durable timestamp is greater than their commit timestamp, which is that it&apos;s possible for another transaction to read them and commit before them, then get checkpointed without them, such that a crash causes the first transaction to disappear but not the second that depended on it.&lt;/p&gt;

&lt;p&gt;See &lt;a href=&quot;https://jira.mongodb.org/browse/WT-8747&quot; title=&quot;Reading between commit_timestamp and durable_timestamp can produce inconsistency&quot; class=&quot;issue-link&quot; data-issue-key=&quot;WT-8747&quot;&gt;&lt;del&gt;WT-8747&lt;/del&gt;&lt;/a&gt; for additional information and examples.&lt;/p&gt;

&lt;p&gt;This is a potential data consistency error.&lt;/p&gt;

&lt;p&gt;The ideal fix for WiredTiger is to return ::WT_ROLLBACK to the reader, which requires the reader to handle transaction rollback and which may not be possible for Server. We considered returning ::WT_NOTFOUND in this case (although that is problematical as well and could lead to its own problems), but patch builds returning the two different errors have roughly similar numbers of failures.&lt;/p&gt;

&lt;p&gt;The patch build returning ::WT_ROLLBACK is here: &lt;a href=&quot;https://evergreen.mongodb.com/version/61fc61400305b973ad2bf953?redirect_spruce_users=true&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://evergreen.mongodb.com/version/61fc61400305b973ad2bf953?redirect_spruce_users=true&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The patch build returning ::WT_NOTFOUND is here: &lt;a href=&quot;https://evergreen.mongodb.com/version/61fd6248a4cf472d4bc3243c?redirect_spruce_users=true&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://evergreen.mongodb.com/version/61fd6248a4cf472d4bc3243c?redirect_spruce_users=true&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Can someone please help us investigate this problem? &#8211; Thanks!&lt;/p&gt;

&lt;p&gt;cc: &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=geert.bosch&quot; class=&quot;user-hover&quot; rel=&quot;geert.bosch&quot;&gt;geert.bosch&lt;/a&gt;, &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=louis.williams&quot; class=&quot;user-hover&quot; rel=&quot;louis.williams&quot;&gt;louis.williams&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
        <key id="1977888">SERVER-63322</key>
            <summary>Reading between commit_timestamp and durable_timestamp can produce inconsistency </summary>
                <type id="1" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14703&amp;avatarType=issuetype">Bug</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="13203">Gone away</resolution>
                                        <assignee username="backlog-server-execution">Backlog - Storage Execution Team</assignee>
                                    <reporter username="keith.bostic@mongodb.com">Keith Bostic</reporter>
                        <labels>
                    </labels>
                <created>Fri, 4 Feb 2022 21:34:30 +0000</created>
                <updated>Fri, 27 Oct 2023 20:45:41 +0000</updated>
                            <resolved>Thu, 24 Feb 2022 16:19:25 +0000</resolved>
                                                                                        <votes>0</votes>
                                    <watches>9</watches>
                                                                                                                <comments>
                            <comment id="4374609" author="henrik.edin" created="Thu, 24 Feb 2022 16:19:51 +0000"  >&lt;p&gt;Closed this ticket per your comment &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=keith.bostic&quot; class=&quot;user-hover&quot; rel=&quot;keith.bostic&quot;&gt;keith.bostic&lt;/a&gt;. Reopen if needed.&lt;/p&gt;</comment>
                            <comment id="4374471" author="keith.bostic" created="Thu, 24 Feb 2022 15:53:21 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jordi.olivares-provencio&quot; class=&quot;user-hover&quot; rel=&quot;jordi.olivares-provencio&quot;&gt;jordi.olivares-provencio&lt;/a&gt;, I think &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-63322&quot; title=&quot;Reading between commit_timestamp and durable_timestamp can produce inconsistency &quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-63322&quot;&gt;&lt;del&gt;SERVER-63322&lt;/del&gt;&lt;/a&gt; can be closed for now. We can always reopen it if necessary, and there&apos;s no reason for it to clog up your backlog without a clear expectation there is work to do here. &#8211; Thank you!&lt;/p&gt;</comment>
                            <comment id="4374243" author="JIRAUSER1264163" created="Thu, 24 Feb 2022 14:50:38 +0000"  >&lt;p&gt;Moving this back to the backlog in TODO as we need to wait on WT&apos;s decision&lt;/p&gt;</comment>
                            <comment id="4358019" author="JIRAUSER1260915" created="Wed, 16 Feb 2022 07:07:25 +0000"  >&lt;p&gt;Re reads, interesting. I was working from the following premises:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Because WT doesn&apos;t track reads in detail there&apos;s a rule against preparing (or committing) at or before any read timestamp that&apos;s ever been used.&lt;/li&gt;
	&lt;li&gt;Consequently,  if you read at time T (T &amp;gt; stable), you cannot prepare or commit anything further at times &amp;lt;= T, and you might as well move stable up before reading. It is allowed to do that while prepared transactions are still resolving, after all, because reads can&apos;t touch them.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I&apos;m guessing there are distributed coordination reasons why it&apos;s not that simple, and I suppose in particular you can&apos;t move stable up until every node that might take over as coordinator agrees on it. (Probably that&apos;s the wrong terminology, but something like that...) Which means you specifically want to read from committed but not-yet-durable transactions, optimistically. (And unlike WT, which doesn&apos;t have any support for dependent transactions, you&apos;re prepared to deal with the consequences if the things you read later end up aborting.) So the proposed restriction sits right across an important optimization.&lt;/p&gt;

&lt;p&gt;I need to chew on this , but I suspect there&apos;s a solution we can all live with...&lt;/p&gt;</comment>
                            <comment id="4357961" author="daniel.gottlieb@10gen.com" created="Wed, 16 Feb 2022 04:58:15 +0000"  >&lt;blockquote&gt;
&lt;p&gt;That interleaving should not cause problems (unless you never move stable forward) because the new restriction only applies to writes by transactions whose durable timestamp is currently &amp;gt; stable. &lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Thanks for clarifying! I wasn&apos;t aware the stable timestamp was also being compared against to allow a document version to be read. I&apos;ll retract perpetuity claims as the stable timestamp does have to advance for prepared transactions to make progress and return acknowledgment to the client.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Since reading beyond stable is somewhat dubious anyhow I would expect this to be sufficient.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;I disagree. MongoDB does that as part of speculative (majority) committed reads. For those, the waiting happens when the application commits its transaction to guarantee the data it reads/writes will not be rolled back. And because WT does not expose the timestamp information of the data read, we make a worst case guess for read-only transactions.&lt;/p&gt;

&lt;p&gt;There are some reasons to prefer speculative majority reads:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;By waiting at the end, there&apos;s less latency overall as the waiting becomes &quot;pipelined&quot; with the conversational reads/writes an application is doing.&lt;/li&gt;
	&lt;li&gt;Having writers use a &quot;stale&quot; &lt;tt&gt;read_timestamp&lt;/tt&gt; results in unnecessary write conflict errors. For sharded transactions, the likelihood and cost of a write conflict is significant.&lt;/li&gt;
	&lt;li&gt;A more perverse case of (2) is that a single application session may not see its own writes. Even though its Txn1 is &quot;majority&quot; committed, Txn2 may not see the effects of Txn1 and thus write conflict itself! The application receives acknowledgement after the decision was committed, but not necessarily when the data writes are considered committed.&lt;/li&gt;
&lt;/ol&gt;


&lt;blockquote&gt;
&lt;p&gt;Ordering restrictions aren&apos;t enough to avoid the problem, because the two transactions involved can have disjoint write sets; then no one key is accessed or updated out of order. I just posted a concrete example in &lt;a href=&quot;https://jira.mongodb.org/browse/WT-8747&quot; title=&quot;Reading between commit_timestamp and durable_timestamp can produce inconsistency&quot; class=&quot;issue-link&quot; data-issue-key=&quot;WT-8747&quot;&gt;&lt;del&gt;WT-8747&lt;/del&gt;&lt;/a&gt; if anyone else is interested.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Noted. Agreed that&apos;s a better place to understand the WT interleaving.&lt;/p&gt;</comment>
                            <comment id="4357900" author="JIRAUSER1260915" created="Wed, 16 Feb 2022 02:54:17 +0000"  >&lt;p&gt;That interleaving should not cause problems (unless you never move stable forward) because the new restriction only applies to writes by transactions whose durable timestamp is currently &amp;gt; stable. So any timestamp before stable (and before any prepare still in progress) should be accepted. Since reading beyond stable is somewhat dubious anyhow I would expect this to be sufficient.&lt;/p&gt;

&lt;p&gt;My changes failed to honor ignore_prepare; that&apos;s a bug, will fix. But please check that by setting it you aren&apos;t buying the problem back &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; since ignore_prepare is inherently somewhat dangerous.&lt;/p&gt;

&lt;p&gt;Ordering restrictions aren&apos;t enough to avoid the problem, because the two transactions involved can have disjoint write sets; then no one key is accessed or updated out of order. I just posted a concrete example in &lt;a href=&quot;https://jira.mongodb.org/browse/WT-8747&quot; title=&quot;Reading between commit_timestamp and durable_timestamp can produce inconsistency&quot; class=&quot;issue-link&quot; data-issue-key=&quot;WT-8747&quot;&gt;&lt;del&gt;WT-8747&lt;/del&gt;&lt;/a&gt; if anyone else is interested.&lt;/p&gt;</comment>
                            <comment id="4356644" author="daniel.gottlieb@10gen.com" created="Tue, 15 Feb 2022 17:24:39 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jordi.olivares-provencio&quot; class=&quot;user-hover&quot; rel=&quot;jordi.olivares-provencio&quot;&gt;jordi.olivares-provencio&lt;/a&gt;, just because dbhash was the only problem our testing showed and it passes in &lt;tt&gt;ignore_prepared&lt;/tt&gt; doesn&apos;t mean the proposed WT change provides semantics we guarantee today. Consider an application that inserts 2 documents into a collection and updates them with prepared transactions with the following interleaving:&lt;/p&gt;
&lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;| Writer 1                           | Writer 2                          |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;|------------------------------------+-----------------------------------|&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;| BeginTxn                           |                                   |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;| Update A                           |                                   |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;| Prepare 10                         |                                   |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;|                                    | BeginTxn                          |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;|                                    | Update B                          |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;|                                    | Prepare 20                        |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;| Commit :durableTs 30 :commitTs: 10 |                                   |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;| BeginTxn                           |                                   |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;| Update A                           |                                   |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;| Prepare 40                         |                                   |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;|                                    | Commit :durableTs 50 :commitTs 20 |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;|                                    | BeginTxn                          |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;|                                    | Update B                          |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;|                                    | Prepare 60                        |&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt;

&lt;p&gt;If we extend that interleaving in perpetuity, every timestamp a reader that wants to see both A and B can choose would fall into a WT_UPDATE&apos;s range of commitTs -&amp;gt; durableTs on either A or B. The collection would be completely unavailable to those readers.&lt;/p&gt;

&lt;p&gt;The premise where commitTs -&amp;gt; durableTs has a problematic window relies on the premise that the application (i.e: MongoDB) is breaking a contract. If we&apos;re in a world today where we are breaking that contract in some places, we should fix those. If we can&apos;t fix those, the proposed solution at least has legs. But I would still flag it as a major change in functionality that would likely require a lot of approval to push through.&lt;/p&gt;</comment>
                            <comment id="4356575" author="JIRAUSER1264163" created="Tue, 15 Feb 2022 17:05:42 +0000"  >&lt;p&gt;Waiting until WT patches the requested functionality of respecting &lt;tt&gt;ignore_prepare&lt;/tt&gt; so that it doesn&apos;t return prepare conflicts&lt;/p&gt;</comment>
                            <comment id="4355442" author="JIRAUSER1264163" created="Tue, 15 Feb 2022 10:19:34 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=louis.williams&quot; class=&quot;user-hover&quot; rel=&quot;louis.williams&quot;&gt;louis.williams&lt;/a&gt; &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=daniel.gottlieb&quot; class=&quot;user-hover&quot; rel=&quot;daniel.gottlieb&quot;&gt;daniel.gottlieb&lt;/a&gt; On a second review of the code I believe that the timeout might not even be necessary as long as WT can accurately ignore Prepared Transactions when requested by the transaction.&lt;/p&gt;

&lt;p&gt;As I mentioned in a previous comment, the dbhash function was the only one at issue with this causing a deadlock. The problem is that I now realise that the deadlock shouldn&apos;t have happened in the first place because dbHash explicitly ignores prepare conflicts too. So the WT_PREPARE_CONFLICT shouldn&apos;t have been returned in the first place.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=keith.bostic&quot; class=&quot;user-hover&quot; rel=&quot;keith.bostic&quot;&gt;keith.bostic&lt;/a&gt; I believe that as long as WT respects the &lt;tt&gt;ignore_prepare&lt;/tt&gt; option in a transaction we shouldn&apos;t have to make modification in our code.&lt;/p&gt;</comment>
                            <comment id="4355364" author="louis.williams" created="Tue, 15 Feb 2022 09:47:01 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=daniel.gottlieb&quot; class=&quot;user-hover&quot; rel=&quot;daniel.gottlieb&quot;&gt;daniel.gottlieb&lt;/a&gt;&#160;this is a good point. The sequence described in&#160;&lt;a href=&quot;https://jira.mongodb.org/browse/WT-8747&quot; title=&quot;Reading between commit_timestamp and durable_timestamp can produce inconsistency&quot; class=&quot;issue-link&quot; data-issue-key=&quot;WT-8747&quot;&gt;&lt;del&gt;WT-8747&lt;/del&gt;&lt;/a&gt; writes with a durable timestamp 25 after an update with a durable timestamp of 30, which I would expect to trigger an assertion about out-of-order timestamps.&lt;/p&gt;</comment>
                            <comment id="4353962" author="daniel.gottlieb@10gen.com" created="Mon, 14 Feb 2022 17:37:14 +0000"  >&lt;p&gt;I don&apos;t think it&apos;s viable to make readers unavailable if their read timestamp is between the durable and commit timestamp of a WT_UPDATE. Our prepared transaction system is built on the premise that readers can choose any timestamp without regard to falling on some implementation detail boundary.&lt;/p&gt;

&lt;p&gt;To write some claims down about how MDB uses commit + durable timestamps on adjacent WT_UPDATEs in an update chain: &lt;tt&gt;Txn_first&lt;/tt&gt; happens before &lt;tt&gt;Txn_second&lt;/tt&gt;&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;&lt;tt&gt;CommitTS_first&lt;/tt&gt; &amp;lt;= &lt;tt&gt;DurableTS_first&lt;/tt&gt;&lt;/li&gt;
	&lt;li&gt;&lt;tt&gt;CommitTs_second&lt;/tt&gt; &amp;lt;= &lt;tt&gt;DurableTS_second&lt;/tt&gt;&lt;/li&gt;
	&lt;li&gt;&lt;tt&gt;DurableTS_first&lt;/tt&gt; &amp;lt;= &lt;tt&gt;CommitTS_second&lt;/tt&gt;&lt;/li&gt;
	&lt;li&gt;By consequence of 2 and 3: &lt;tt&gt;DurableTS_first&lt;/tt&gt; &amp;lt;= &lt;tt&gt;DurableTS_second&lt;/tt&gt;&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;I expect the &lt;tt&gt;write_timestamp_usage=ordered&lt;/tt&gt; setting to fire if any of those assertions fail.&lt;/p&gt;</comment>
                            <comment id="4353510" author="JIRAUSER1264163" created="Mon, 14 Feb 2022 15:31:28 +0000"  >&lt;p&gt;Hi again &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=keith.bostic&quot; class=&quot;user-hover&quot; rel=&quot;keith.bostic&quot;&gt;keith.bostic&lt;/a&gt;, we discussed it internally and it seems that it is a possible fix we can do on our end. We&apos;ll preemptively be committing it into our codebase in preparation for your patch.&lt;/p&gt;

&lt;p&gt;In parallel we discovered the second error present in our tests. We have logic on our end that is setting the &lt;tt&gt;ignore_prepare&lt;/tt&gt; option in the transaction but it seems that it is being ignored in the current patch. This means that even though it specifies that WT_PREPARED_CONFLICT should not be an expected outcome it is receiving it and leading to issues. Would it be possible to fix it in your patch?&lt;/p&gt;</comment>
                            <comment id="4351220" author="keith.bostic" created="Fri, 11 Feb 2022 19:23:37 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jordi.olivares-provencio&quot; class=&quot;user-hover&quot; rel=&quot;jordi.olivares-provencio&quot;&gt;jordi.olivares-provencio&lt;/a&gt;, thank you!&lt;/p&gt;

&lt;p&gt;Is this a reasonable &quot;real fix&quot; for MDB Server? To the extent that ::WT_PREPARE_CONFLICT is resolved by a housekeeping thread advancing stable, it seems reasonable there would not necessarily be another concurrent transaction running.&lt;/p&gt;</comment>
                            <comment id="4350424" author="JIRAUSER1264163" created="Fri, 11 Feb 2022 15:18:45 +0000"  >&lt;p&gt;Adding a 1 millisecond timeout to the lock seems to fix a great deal of these issues as can be seen here: &lt;a href=&quot;https://spruce.mongodb.com/version/62064f15d6d80a25a22f5dda/tasks?sorts=STATUS%3AASC%3BBASE_STATUS%3ADESC&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://spruce.mongodb.com/version/62064f15d6d80a25a22f5dda/tasks?sorts=STATUS%3AASC%3BBASE_STATUS%3ADESC&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="4349998" author="JIRAUSER1264163" created="Fri, 11 Feb 2022 12:04:12 +0000"  >&lt;p&gt;Going by the error logs and the core dump I believe the concurrent dbHash command execution is to blame here. Looking at the core dumps there&apos;s a deadlock occurring in the &lt;tt&gt;DBHashCmd::_hashCollection&lt;/tt&gt; method while iterating the cursor. It seems that the method on our end is checking if the result of iterating it returns a WT_PREPARE_CONFLICT and if so waits until another WUOW commits or aborts in order to try again. The problem is that in those tests this won&apos;t happen as there is no other concurrent transaction, thus leading to a deadlock.&lt;/p&gt;</comment>
                            <comment id="4345467" author="keith.bostic" created="Wed, 9 Feb 2022 16:49:33 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=louis.williams&quot; class=&quot;user-hover&quot; rel=&quot;louis.williams&quot;&gt;louis.williams&lt;/a&gt;, we now have a WiredTiger PR that returns ::WT_PREPARE_CONFLICT on this error and we&apos;ve run the patch build. It&apos;s cleaner than before, but there is still a significant amount of fallout: &lt;a href=&quot;https://spruce.mongodb.com/version/620312875623432d870f0ea5/tasks&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://spruce.mongodb.com/version/620312875623432d870f0ea5/tasks&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;If we could have someone help us understand where this change is causing problems for server, that would be terrific. &#8211; Thanks!&lt;/p&gt;</comment>
                            <comment id="4341804" author="keith.bostic" created="Tue, 8 Feb 2022 13:33:23 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=louis.williams&quot; class=&quot;user-hover&quot; rel=&quot;louis.williams&quot;&gt;louis.williams&lt;/a&gt;, it&apos;s a durability problem we&apos;re reasonably confident isn&apos;t a real problem in MongoDB server. We&apos;d like to get it out of the way to eliminate another data consistency corner case, but we don&apos;t believe there are actual problems in the server.&lt;/p&gt;

&lt;p&gt;It&apos;s currently stalled on us rewriting our patch to use ::WT_PREPARE_CONFLICT as the return failure code and re-running the patch build to identify remaining failures, and that will happen today.&lt;/p&gt;</comment>
                            <comment id="4341521" author="louis.williams" created="Tue, 8 Feb 2022 10:35:03 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=keith.bostic&quot; class=&quot;user-hover&quot; rel=&quot;keith.bostic&quot;&gt;keith.bostic&lt;/a&gt;, what is the current priority of this ticket?&lt;/p&gt;</comment>
                            <comment id="4341035" author="keith.bostic" created="Tue, 8 Feb 2022 00:28:44 +0000"  >&lt;p&gt;We&apos;ve been talking this over inside the WiredTiger group, and we think a better way forward might be to return ::WT_PREPARE_CONFLICT instead of ::WT_ROLLBACK or ::WT_NOTFOUND. Preliminary testing indicates this approach leads to fewer problems, and so we&apos;re going to try implementing it for real and do some more testing, the results of which we should have ready for review in a day or so.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                        <issuelink>
            <issuekey id="1973731">WT-8747</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="1982892">SERVER-63615</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>19.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18555" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname># of Sprints</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    <customfield id="customfield_12751" key="com.atlassian.jira.plugin.system.customfieldtypes:multiselect">
                        <customfieldname>Assigned Teams</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="25136"><![CDATA[Storage Execution]]></customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Tue, 8 Feb 2022 10:35:03 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        1 year, 49 weeks, 6 days ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[]]></customfieldvalue>


                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10057" key="com.atlassian.jira.toolkit:lastusercommented">
                        <customfieldname>Last comment by Customer</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>true</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10056" key="com.atlassian.jira.toolkit:lastupdaterorcommenter">
                        <customfieldname>Last commenter</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>luke.bonanomi@mongodb.com</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            1 year, 49 weeks, 6 days ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    <customfield id="customfield_10032" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Operating System</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10026"><![CDATA[ALL]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>backlog-server-execution</customfieldvalue>
            <customfieldvalue>daniel.gottlieb@mongodb.com</customfieldvalue>
            <customfieldvalue>dholland+wt@sauclovia.org</customfieldvalue>
            <customfieldvalue>henrik.edin@mongodb.com</customfieldvalue>
            <customfieldvalue>jordi.olivares-provencio@mongodb.com</customfieldvalue>
            <customfieldvalue>keith.bostic@mongodb.com</customfieldvalue>
            <customfieldvalue>louis.williams@mongodb.com</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|i0j8z3:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|i02bzz:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_23361" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Requested By</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_10557" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="5588">Execution Team 2022-02-21</customfieldvalue>
    <customfieldvalue id="5811">Execution Team 2022-03-07</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10053" key="com.atlassian.jira.ext.charting:timeinstatus">
                        <customfieldname>Time In Status</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_22870" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Triagers</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_14350" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>serverRank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|i0iv4f:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                    </customfields>
    </item>
</channel>
</rss>