Re: Assertion failure on hot standby

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