On Fri, Nov 26, 2010 at 7:40 AM, Simon Riggs <simon@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