From 102aeedfb9bf01b419563151846ebbd1f01f4a5f Mon Sep 17 00:00:00 2001 From: Simon Riggs Date: Mon, 15 Nov 2010 09:31:23 +0000 Subject: [PATCH] Avoid spurious Hot Standby conflicts from btree delete records. 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. --- src/backend/storage/ipc/standby.c | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c index 9f71c1a156a..154147e44c2 100644 --- a/src/backend/storage/ipc/standby.c +++ b/src/backend/storage/ipc/standby.c @@ -266,21 +266,13 @@ ResolveRecoveryConflictWithSnapshot(TransactionId latestRemovedXid, RelFileNode /* * If we get passed InvalidTransactionId then we are a little surprised, - * but it is theoretically possible, so spit out a DEBUG1 message, but not - * one that needs translating. - * - * We grab latestCompletedXid instead because this is the very latest - * value it could ever be. + * but it is theoretically possible in normal running. It also happens + * when replaying already applied WAL records after a standby crash or + * restart. If latestRemovedXid is invalid then there is no conflict. That + * rule applies across all record types that suffer from this conflict. */ if (!TransactionIdIsValid(latestRemovedXid)) - { - elog(DEBUG1, "invalid latestremovexXid reported, using latestcompletedxid instead"); - - LWLockAcquire(ProcArrayLock, LW_SHARED); - latestRemovedXid = ShmemVariableCache->latestCompletedXid; - LWLockRelease(ProcArrayLock); - } - Assert(TransactionIdIsValid(latestRemovedXid)); + return; backends = GetConflictingVirtualXIDs(latestRemovedXid, node.dbNode);