On Fri, Nov 26, 2010 at 7:40 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > As to solutions, it cannot be acceptable to ignore some locks just > because an xid has not been assigned.
Even if GetRunningTransactionLocks ignores such a lock, it's eventually WAL-logged by LogAccessExclusiveLock, isn't it? > 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. Right. > 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(); s/GetCurrentTransactionId/GetTopTransactionId? > Any objections to that fix? Or can we call LogAccessExclusiveLock before registering the lock? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
