mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2025-03-07 19:47:50 +08:00
Code Issues Packages Projects Releases Wiki Activity

Avoid spurious Hot Standby conflicts from btree delete records.

Browse Source 
Similar conflicts were already avoided for related record types.
Massive over-caution resulted in a usability bug. Clear theoretical
basis for doing this is now confirmed by me.
Request to remove from Heikki (twice), over-caution by me.
This commit is contained in:
Simon Riggs 2010-11-15 09:31:23 +00:00
parent e6b3802518
commit 102aeedfb9
1 changed files with 5 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/backend/storage/ipc/standby.c
View File

@ -266,21 +266,13 @@ ResolveRecoveryConflictWithSnapshot(TransactionId latestRemovedXid, RelFileNode
/* /*
* If we get passed InvalidTransactionId then we are a little surprised, * If we get passed InvalidTransactionId then we are a little surprised,
* but it is theoretically possible, so spit out a DEBUG1 message, but not * but it is theoretically possible in normal running. It also happens
* one that needs translating. * when replaying already applied WAL records after a standby crash or
* * restart. If latestRemovedXid is invalid then there is no conflict. That
* We grab latestCompletedXid instead because this is the very latest * rule applies across all record types that suffer from this conflict.
* value it could ever be.
*/ */
if (!TransactionIdIsValid(latestRemovedXid)) if (!TransactionIdIsValid(latestRemovedXid))
{ return;
elog(DEBUG1, "invalid latestremovexXid reported, using latestcompletedxid instead");
LWLockAcquire(ProcArrayLock, LW_SHARED);
latestRemovedXid = ShmemVariableCache->latestCompletedXid;
LWLockRelease(ProcArrayLock);
}
Assert(TransactionIdIsValid(latestRemovedXid));
backends = GetConflictingVirtualXIDs(latestRemovedXid, backends = GetConflictingVirtualXIDs(latestRemovedXid,
node.dbNode); node.dbNode);