On Thu, 2010-11-25 at 16:59 +0900, Fujii Masao wrote:
> To solve the problem, ISTM that XID should be assigned before the
> information about AccessExclusive lock becomes visible to another
> process. Or CHECKPOINT (i.e., GetRunningTransactionLocks) should
> ignore the locks with XID = 0.
First, thanks for pursuing this. I realise I made the mistake of
assuming there was just one bug; I see that the bug Heikki was
discussing is a separate issue.
As to solutions, it cannot be acceptable to ignore some locks just
because an xid has not been assigned.
If I understand you correctly, it seems possible to generate an
AccessExclusiveLock before an xid is assigned, so that its possible to
log that situation before the transaction assigns an xid slightly later.
So there's a narrow window where we can generate a lock WAL record with
xid 0. The sensible resolution is to ensure that all
AccessExclusiveLocks have an xid assigned prior to them registering
their proclock.
That would mean running GetCurrentTransactionId() inside LockAcquire()
if (lockmode >= AccessExclusiveLock && locktag->locktag_type == LOCKTAG_RELATION && !RecoveryInProgress())(void)
GetCurrentTransactionId();
Any objections to that fix?
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
