Movatterモバイル変換

[0]ホーム
URL:

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

 Sign up
Appearance settings

Commit5c8dabe

Browse files
committed
Reconsider when to wait for WAL flushes/syncrep during commit.
Up to now RecordTransactionCommit() waited for WAL to be flushed (ifsynchronous_commit != off) and to be synchronously replicated (ifenabled), even if a transaction did not have a xid assigned. The primaryreason for that is that sequence's nextval() did not assign a xid, butare worthwhile to wait for on commit.This can be problematic because sometimes read only transactions dowrite WAL, e.g. HOT page prune records. That then could lead to read onlytransactions having to wait during commit. Not something people expectin a read only transaction.This lead to such strange symptoms as backends being seemingly stuckduring connection establishment when all synchronous replicas aredown. Especially annoying when said stuck connection is the standbytrying to reconnect to allow syncrep again...This behavior also is involved in a rather complicated <= 9.4 bug wherethe transaction started by catchup interrupt processing waited forsyncrep using latches, but didn't get the wakeup because it was alreadyrunning inside the same overloaded signal handler. Fix the issue heredoesn't properly solve that issue, merely papers over the problems. In9.5 catchup interrupts aren't processed out of signal handlers anymore.To fix all this, make nextval() acquire a top level xid, and only wait fortransaction commit if a transaction both acquired a xid and emitted WALrecords. If only a xid has been assigned we don't uselessly want towait just because of writes to temporary/unlogged tables; if only WALhas been written we don't want to wait just because of HOT prunes.The xid assignment in nextval() is unlikely to cause overhead inreal-world workloads. For one it only happens SEQ_LOG_VALS/32 valuesanyway, for another only usage of nextval() without using the result inan insert or similar is affected.Discussion: 20150223165359.GF30784@awork2.anarazel.de, 369698E947874884A77849D8FE3680C2@maumau, 5CF4ABBA67674088B3941894E22A0D25@maumauPer complaint from maumau and Thom BrownBackpatch all the way back; 9.0 doesn't have syncrep, but it seemsbetter to be consistent behavior across all maintained branches.
1 parent034d05d commit5c8dabe

File tree

2 files changed

+39
-12
lines changed

2 files changed

+39
-12
lines changed

‎src/backend/access/transam/xact.c

Lines changed: 17 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -949,10 +949,9 @@ RecordTransactionCommit(void)
949949

950950
/*
951951
* If we didn't create XLOG entries, we're done here; otherwise we
952-
* should flush those entries the same as a commit record. (An
953-
* example of a possible record that wouldn't cause an XID to be
954-
* assigned is a sequence advance record due to nextval() --- we want
955-
* to flush that to disk before reporting commit.)
952+
* should trigger flushing those entries the same as a commit record
953+
* would. This will primarily happen for HOT pruning and the like; we
954+
* want these to be flushed to disk in due time.
956955
*/
957956
if (!wrote_xlog)
958957
gotocleanup;
@@ -1044,11 +1043,13 @@ RecordTransactionCommit(void)
10441043
/*
10451044
* Check if we want to commit asynchronously. We can allow the XLOG flush
10461045
* to happen asynchronously if synchronous_commit=off, or if the current
1047-
* transaction has not performed any WAL-logged operation. The latter
1048-
* case can arise if the current transaction wrote only to temporary
1049-
* and/or unlogged tables. In case of a crash, the loss of such a
1050-
* transaction will be irrelevant since temp tables will be lost anyway,
1051-
* and unlogged tables will be truncated. (Given the foregoing, you might
1046+
* transaction has not performed any WAL-logged operation or didn't assign
1047+
* a xid. The transaction can end up not writing any WAL, even if it has
1048+
* a xid, if it only wrote to temporary and/or unlogged tables. It can
1049+
* end up having written WAL without an xid if it did HOT pruning. In
1050+
* case of a crash, the loss of such a transaction will be irrelevant;
1051+
* temp tables will be lost anyway, unlogged tables will be truncated and
1052+
* HOT pruning will be done again later. (Given the foregoing, you might
10521053
* think that it would be unnecessary to emit the XLOG record at all in
10531054
* this case, but we don't currently try to do that. It would certainly
10541055
* cause problems at least in Hot Standby mode, where the
@@ -1064,7 +1065,8 @@ RecordTransactionCommit(void)
10641065
* if all to-be-deleted tables are temporary though, since they are lost
10651066
* anyway if we crash.)
10661067
*/
1067-
if ((wrote_xlog&&synchronous_commit>SYNCHRONOUS_COMMIT_OFF)||
1068+
if ((wrote_xlog&&markXidCommitted&&
1069+
synchronous_commit>SYNCHRONOUS_COMMIT_OFF)||
10681070
forceSyncCommit||nrels>0)
10691071
{
10701072
/*
@@ -1136,12 +1138,15 @@ RecordTransactionCommit(void)
11361138
latestXid=TransactionIdLatest(xid,nchildren,children);
11371139

11381140
/*
1139-
* Wait for synchronous replication, if required.
1141+
* Wait for synchronous replication, if required. Similar to the decision
1142+
* above about using committing asynchronously we only want to wait if
1143+
* this backend assigned a xid and wrote WAL. No need to wait if a xid
1144+
* was assigned due to temporary/unlogged tables or due to HOT pruning.
11401145
*
11411146
* Note that at this stage we have marked clog, but still show as running
11421147
* in the procarray and continue to hold locks.
11431148
*/
1144-
if (wrote_xlog)
1149+
if (wrote_xlog&&markXidCommitted)
11451150
SyncRepWaitForLSN(XactLastRecEnd);
11461151

11471152
/* Reset XactLastRecEnd until the next transaction writes something */

‎src/backend/commands/sequence.c

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -343,6 +343,10 @@ fill_seq_with_data(Relation rel, HeapTuple tuple)
343343
*/
344344
LockBuffer(buf,BUFFER_LOCK_EXCLUSIVE);
345345

346+
/* check the comment above nextval_internal()'s equivalent call. */
347+
if (RelationNeedsWAL(rel))
348+
GetTopTransactionId();
349+
346350
START_CRIT_SECTION();
347351

348352
{
@@ -436,6 +440,10 @@ AlterSequence(AlterSeqStmt *stmt)
436440
/* Note that we do not change the currval() state */
437441
elm->cached=elm->last;
438442

443+
/* check the comment above nextval_internal()'s equivalent call. */
444+
if (RelationNeedsWAL(seqrel))
445+
GetTopTransactionId();
446+
439447
/* Now okay to update the on-disk tuple */
440448
START_CRIT_SECTION();
441449

@@ -669,6 +677,16 @@ nextval_internal(Oid relid)
669677

670678
last_used_seq=elm;
671679

680+
/*
681+
* If something needs to be WAL logged, acquire an xid, so this
682+
* transaction's commit will trigger a WAL flush and wait for
683+
* syncrep. It's sufficient to ensure the toplevel transaction has a xid,
684+
* no need to assign xids subxacts, that'll already trigger a appropriate
685+
* wait. (Have to do that here, so we're outside the critical section)
686+
*/
687+
if (logit&&RelationNeedsWAL(seqrel))
688+
GetTopTransactionId();
689+
672690
/* ready to change the on-disk (or really, in-buffer) tuple */
673691
START_CRIT_SECTION();
674692

@@ -863,6 +881,10 @@ do_setval(Oid relid, int64 next, bool iscalled)
863881
/* In any case, forget any future cached numbers */
864882
elm->cached=elm->last;
865883

884+
/* check the comment above nextval_internal()'s equivalent call. */
885+
if (RelationNeedsWAL(seqrel))
886+
GetTopTransactionId();
887+
866888
/* ready to change the on-disk (or really, in-buffer) tuple */
867889
START_CRIT_SECTION();
868890

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp