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

Commitabce8dc

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 parent4651e37 commitabce8dc

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
@@ -996,10 +996,9 @@ RecordTransactionCommit(void)
996996

997997
/*
998998
* If we didn't create XLOG entries, we're done here; otherwise we
999-
* should flush those entries the same as a commit record. (An
1000-
* example of a possible record that wouldn't cause an XID to be
1001-
* assigned is a sequence advance record due to nextval() --- we want
1002-
* to flush that to disk before reporting commit.)
999+
* should trigger flushing those entries the same as a commit record
1000+
* would. This will primarily happen for HOT pruning and the like; we
1001+
* want these to be flushed to disk in due time.
10031002
*/
10041003
if (!wrote_xlog)
10051004
gotocleanup;
@@ -1122,11 +1121,13 @@ RecordTransactionCommit(void)
11221121
/*
11231122
* Check if we want to commit asynchronously. We can allow the XLOG flush
11241123
* to happen asynchronously if synchronous_commit=off, or if the current
1125-
* transaction has not performed any WAL-logged operation. The latter
1126-
* case can arise if the current transaction wrote only to temporary
1127-
* and/or unlogged tables. In case of a crash, the loss of such a
1128-
* transaction will be irrelevant since temp tables will be lost anyway,
1129-
* and unlogged tables will be truncated. (Given the foregoing, you might
1124+
* transaction has not performed any WAL-logged operation or didn't assign
1125+
* a xid. The transaction can end up not writing any WAL, even if it has
1126+
* a xid, if it only wrote to temporary and/or unlogged tables. It can
1127+
* end up having written WAL without an xid if it did HOT pruning. In
1128+
* case of a crash, the loss of such a transaction will be irrelevant;
1129+
* temp tables will be lost anyway, unlogged tables will be truncated and
1130+
* HOT pruning will be done again later. (Given the foregoing, you might
11301131
* think that it would be unnecessary to emit the XLOG record at all in
11311132
* this case, but we don't currently try to do that. It would certainly
11321133
* cause problems at least in Hot Standby mode, where the
@@ -1142,7 +1143,8 @@ RecordTransactionCommit(void)
11421143
* if all to-be-deleted tables are temporary though, since they are lost
11431144
* anyway if we crash.)
11441145
*/
1145-
if ((wrote_xlog&&synchronous_commit>SYNCHRONOUS_COMMIT_OFF)||
1146+
if ((wrote_xlog&&markXidCommitted&&
1147+
synchronous_commit>SYNCHRONOUS_COMMIT_OFF)||
11461148
forceSyncCommit||nrels>0)
11471149
{
11481150
XLogFlush(XactLastRecEnd);
@@ -1191,12 +1193,15 @@ RecordTransactionCommit(void)
11911193
latestXid=TransactionIdLatest(xid,nchildren,children);
11921194

11931195
/*
1194-
* Wait for synchronous replication, if required.
1196+
* Wait for synchronous replication, if required. Similar to the decision
1197+
* above about using committing asynchronously we only want to wait if
1198+
* this backend assigned a xid and wrote WAL. No need to wait if a xid
1199+
* was assigned due to temporary/unlogged tables or due to HOT pruning.
11951200
*
11961201
* Note that at this stage we have marked clog, but still show as running
11971202
* in the procarray and continue to hold locks.
11981203
*/
1199-
if (wrote_xlog)
1204+
if (wrote_xlog&&markXidCommitted)
12001205
SyncRepWaitForLSN(XactLastRecEnd);
12011206

12021207
/* 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"
@@ -347,6 +348,10 @@ fill_seq_with_data(Relation rel, HeapTuple tuple)
347348
*/
348349
LockBuffer(buf,BUFFER_LOCK_EXCLUSIVE);
349350

351+
/* check the comment above nextval_internal()'s equivalent call. */
352+
if (RelationNeedsWAL(rel))
353+
GetTopTransactionId();
354+
350355
START_CRIT_SECTION();
351356

352357
{
@@ -447,6 +452,10 @@ AlterSequence(AlterSeqStmt *stmt)
447452
/* Note that we do not change the currval() state */
448453
elm->cached=elm->last;
449454

455+
/* check the comment above nextval_internal()'s equivalent call. */
456+
if (RelationNeedsWAL(seqrel))
457+
GetTopTransactionId();
458+
450459
/* Now okay to update the on-disk tuple */
451460
START_CRIT_SECTION();
452461

@@ -692,6 +701,16 @@ nextval_internal(Oid relid)
692701

693702
last_used_seq=elm;
694703

704+
/*
705+
* If something needs to be WAL logged, acquire an xid, so this
706+
* transaction's commit will trigger a WAL flush and wait for
707+
* syncrep. It's sufficient to ensure the toplevel transaction has a xid,
708+
* no need to assign xids subxacts, that'll already trigger a appropriate
709+
* wait. (Have to do that here, so we're outside the critical section)
710+
*/
711+
if (logit&&RelationNeedsWAL(seqrel))
712+
GetTopTransactionId();
713+
695714
/* ready to change the on-disk (or really, in-buffer) tuple */
696715
START_CRIT_SECTION();
697716

@@ -885,6 +904,10 @@ do_setval(Oid relid, int64 next, bool iscalled)
885904
/* In any case, forget any future cached numbers */
886905
elm->cached=elm->last;
887906

907+
/* check the comment above nextval_internal()'s equivalent call. */
908+
if (RelationNeedsWAL(seqrel))
909+
GetTopTransactionId();
910+
888911
/* ready to change the on-disk (or really, in-buffer) tuple */
889912
START_CRIT_SECTION();
890913

0 commit comments

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