database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-06 07:49:08 +03:00
Code Activity

Resolve timing issue with logging locks for Hot Standby.

Browse Source 
We log AccessExclusiveLocks for replay onto standby nodes,
but because of timing issues on ProcArray it is possible to
log a lock that is still held by a just committed transaction
that is very soon to be removed. To avoid any timing issue we
avoid applying locks made by transactions with InvalidXid.

Simon Riggs, bug report Tom Lane, diagnosis Pavan Deolasee
This commit is contained in:
Simon Riggs
2012-01-23 23:37:32 +00:00
parent b8a91d9d1c
commit c172b7b02e
4 changed files with 88 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
src/backend/storage/lmgr/lock.c
View File

@@ -3190,8 +3190,18 @@ GetRunningTransactionLocks(int *nlocks)
PGPROC *proc = proclock->tag.myProc;
PGXACT *pgxact = &ProcGlobal->allPgXact[proc->pgprocno];
LOCK *lock = proclock->tag.myLock;
TransactionId xid = pgxact->xid;
accessExclusiveLocks[index].xid = pgxact->xid;
/*
* Don't record locks for transactions if we know they have already
* issued their WAL record for commit but not yet released lock.
* It is still possible that we see locks held by already complete
* transactions, if they haven't yet zeroed their xids.
*/
if (!TransactionIdIsValid(xid))
continue;
accessExclusiveLocks[index].xid = xid;
accessExclusiveLocks[index].dbOid = lock->tag.locktag_field1;
accessExclusiveLocks[index].relOid = lock->tag.locktag_field2;