Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

Commit 5a2c184

Browse filesBrowse files
anarazelanarazel
committed
Fix xmin/xmax horizon computation during logical decoding initialization.
When building the initial historic catalog snapshot there were scenarios where snapbuild.c would use incorrect xmin/xmax values when starting from a xl_running_xacts record. The values used were always a bit suspect, but happened to be correct in the easy to test cases. Notably the values used when the the initial snapshot was computed while no other transactions were running were correct. This is likely to be the cause of the occasional buildfarm failures on animals markhor and tick; but it's quite possible to reproduce problems without CLOBBER_CACHE_ALWAYS. Backpatch to 9.4, where logical decoding was introduced.
1 parent 81c4508 commit 5a2c184
Copy full SHA for 5a2c184

File tree

Expand file treeCollapse file tree

1 file changed

+13
-7
lines changed
Filter options
Expand file treeCollapse file tree

1 file changed

+13
-7
lines changed

‎src/backend/replication/logical/snapbuild.c

Copy file name to clipboardExpand all lines: src/backend/replication/logical/snapbuild.c
+13-7Lines changed: 13 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@
2828
*
2929
* As the percentage of transactions modifying the catalog normally is fairly
3030
* small in comparisons to ones only manipulating user data, we keep track of
31-
* the committed catalog modifying ones inside (xmin, xmax) instead of keeping
31+
* the committed catalog modifying ones inside [xmin, xmax) instead of keeping
3232
* track of all running transactions like it's done in a normal snapshot. Note
3333
* that we're generally only looking at transactions that have acquired an
3434
* xid. That is we keep a list of transactions between snapshot->(xmin, xmax)
@@ -1250,10 +1250,11 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
12501250
/* can decode everything after this */
12511251
builder->start_decoding_at = lsn + 1;
12521252

1253-
builder->xmin = running->oldestRunningXid;
1254-
builder->xmax = running->latestCompletedXid;
1255-
TransactionIdAdvance(builder->xmax);
1253+
/* As no transactions were running xmin/xmax can be trivially set. */
1254+
builder->xmin = running->nextXid; /* < are finished */
1255+
builder->xmax = running->nextXid; /* >= are running */
12561256

1257+
/* so we can safely use the faster comparisons */
12571258
Assert(TransactionIdIsNormal(builder->xmin));
12581259
Assert(TransactionIdIsNormal(builder->xmax));
12591260

@@ -1294,9 +1295,14 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
12941295
* instead of running transactions we don't need to know anything
12951296
* about uncommitted subtransactions.
12961297
*/
1297-
builder->xmin = running->oldestRunningXid;
1298-
builder->xmax = running->latestCompletedXid;
1299-
TransactionIdAdvance(builder->xmax);
1298+
1299+
/*
1300+
* Start with an xmin/xmax that's correct for future, when all the
1301+
* currently running transactions have finished. We'll update both
1302+
* while waiting for the pending transactions to finish.
1303+
*/
1304+
builder->xmin = running->nextXid; /* < are finished */
1305+
builder->xmax = running->nextXid; /* >= are running */
13001306

13011307
/* so we can safely use the faster comparisons */
13021308
Assert(TransactionIdIsNormal(builder->xmin));

0 commit comments

Comments
0 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.