On Wed, Dec 14, 2011 at 12:20 PM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:
> On Wed, Dec 14, 2011 at 4:15 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>>
>> Without the added assert, you'd only notice this if you were running a
>> standby slave --- the zero xid results in an assert failure in WAL
>> replay on the slave end, which is how I found out about this to start
>> with. But since we've not heard reports of such before, I suspect that
>> this is a recently introduced bug; and personally I'd bet money that it
>> was the PGXACT patch that broke it.
>>
>
> I can reproduce this and will look at it in detail.
>
Looking at CommitTransaction(), it seems quite clear to me that we
call ProcArrayEndTransaction() before releasing the locks held by the
transaction. So its quite possible that when
GetRunningTransactionLocks goes through the list of currently held
locks, the pgxact->xid is already cleared. This seems to a old bug to
me and not related to PGXACT work.
In fact, I can force the assertion failure by braking into gdb and
pausing the process running the following statements, right after it
clears the xid by calling ProcArrayEndTransaction(). At that point, if
I hit CHECKPOINT from another session, the assertion fails.
Session 1:
BEGIN;
LOCK TABLE test IN ACCESS EXCLUSIVE MODE;
COMMIT; ==> break after ProcArrayEndTransaction finishes
Session 2:
CHECKPOINT;
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com