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

Commitd721151

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 parent38930e4 commitd721151

File tree

2 files changed

+40
-12
lines changed

2 files changed

+40
-12
lines changed

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

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

10351035
/*
10361036
* If we didn't create XLOG entries, we're done here; otherwise we
1037-
* should flush those entries the same as a commit record. (An
1038-
* example of a possible record that wouldn't cause an XID to be
1039-
* assigned is a sequence advance record due to nextval() --- we want
1040-
* to flush that to disk before reporting commit.)
1037+
* should trigger flushing those entries the same as a commit record
1038+
* would. This will primarily happen for HOT pruning and the like; we
1039+
* want these to be flushed to disk in due time.
10411040
*/
10421041
if (!wrote_xlog)
10431042
gotocleanup;
@@ -1168,11 +1167,13 @@ RecordTransactionCommit(void)
11681167
/*
11691168
* Check if we want to commit asynchronously. We can allow the XLOG flush
11701169
* to happen asynchronously if synchronous_commit=off, or if the current
1171-
* transaction has not performed any WAL-logged operation. The latter
1172-
* case can arise if the current transaction wrote only to temporary
1173-
* and/or unlogged tables. In case of a crash, the loss of such a
1174-
* transaction will be irrelevant since temp tables will be lost anyway,
1175-
* and unlogged tables will be truncated. (Given the foregoing, you might
1170+
* transaction has not performed any WAL-logged operation or didn't assign
1171+
* a xid. The transaction can end up not writing any WAL, even if it has
1172+
* a xid, if it only wrote to temporary and/or unlogged tables. It can
1173+
* end up having written WAL without an xid if it did HOT pruning. In
1174+
* case of a crash, the loss of such a transaction will be irrelevant;
1175+
* temp tables will be lost anyway, unlogged tables will be truncated and
1176+
* HOT pruning will be done again later. (Given the foregoing, you might
11761177
* think that it would be unnecessary to emit the XLOG record at all in
11771178
* this case, but we don't currently try to do that. It would certainly
11781179
* cause problems at least in Hot Standby mode, where the
@@ -1188,7 +1189,8 @@ RecordTransactionCommit(void)
11881189
* if all to-be-deleted tables are temporary though, since they are lost
11891190
* anyway if we crash.)
11901191
*/
1191-
if ((wrote_xlog&&synchronous_commit>SYNCHRONOUS_COMMIT_OFF)||
1192+
if ((wrote_xlog&&markXidCommitted&&
1193+
synchronous_commit>SYNCHRONOUS_COMMIT_OFF)||
11921194
forceSyncCommit||nrels>0)
11931195
{
11941196
XLogFlush(XactLastRecEnd);
@@ -1237,12 +1239,15 @@ RecordTransactionCommit(void)
12371239
latestXid=TransactionIdLatest(xid,nchildren,children);
12381240

12391241
/*
1240-
* Wait for synchronous replication, if required.
1242+
* Wait for synchronous replication, if required. Similar to the decision
1243+
* above about using committing asynchronously we only want to wait if
1244+
* this backend assigned a xid and wrote WAL. No need to wait if a xid
1245+
* was assigned due to temporary/unlogged tables or due to HOT pruning.
12411246
*
12421247
* Note that at this stage we have marked clog, but still show as running
12431248
* in the procarray and continue to hold locks.
12441249
*/
1245-
if (wrote_xlog)
1250+
if (wrote_xlog&&markXidCommitted)
12461251
SyncRepWaitForLSN(XactLastRecEnd);
12471252

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

‎src/backend/commands/sequence.c

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,7 @@
1717
#include"access/htup_details.h"
1818
#include"access/multixact.h"
1919
#include"access/transam.h"
20+
#include"access/xact.h"
2021
#include"access/xlogutils.h"
2122
#include"catalog/dependency.h"
2223
#include"catalog/namespace.h"
@@ -338,6 +339,10 @@ fill_seq_with_data(Relation rel, HeapTuple tuple)
338339
tuple->t_data->t_infomask |=HEAP_XMAX_INVALID;
339340
ItemPointerSet(&tuple->t_data->t_ctid,0,FirstOffsetNumber);
340341

342+
/* check the comment above nextval_internal()'s equivalent call. */
343+
if (RelationNeedsWAL(rel))
344+
GetTopTransactionId();
345+
341346
START_CRIT_SECTION();
342347

343348
MarkBufferDirty(buf);
@@ -422,6 +427,10 @@ AlterSequence(AlterSeqStmt *stmt)
422427
/* Note that we do not change the currval() state */
423428
elm->cached=elm->last;
424429

430+
/* check the comment above nextval_internal()'s equivalent call. */
431+
if (RelationNeedsWAL(seqrel))
432+
GetTopTransactionId();
433+
425434
/* Now okay to update the on-disk tuple */
426435
START_CRIT_SECTION();
427436

@@ -667,6 +676,16 @@ nextval_internal(Oid relid)
667676

668677
last_used_seq=elm;
669678

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

@@ -860,6 +879,10 @@ do_setval(Oid relid, int64 next, bool iscalled)
860879
/* In any case, forget any future cached numbers */
861880
elm->cached=elm->last;
862881

882+
/* check the comment above nextval_internal()'s equivalent call. */
883+
if (RelationNeedsWAL(seqrel))
884+
GetTopTransactionId();
885+
863886
/* ready to change the on-disk (or really, in-buffer) tuple */
864887
START_CRIT_SECTION();
865888

0 commit comments

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