From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Subject: | Re: Assertion failure on hot standby |
Date: | 2010-11-26 02:19:34 |
Message-ID: | AANLkTimqzkgOrZ7bEcVK9GePZx+S1Zo5+6mq=CQqq8=d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 26, 2010 at 7:40 AM, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua Tolley | 2010-11-26 02:31:11 | Re: pg_execute_from_file review |
Previous Message | KaiGai Kohei | 2010-11-26 01:29:00 | Re: [GENERAL] column-level update privs + lock table |