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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers