Re: Nested transactions and tuple header info - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Nested transactions and tuple header info
Date
Msg-id 20040613063238.GA26479@dcc.uchile.cl
Whole thread Raw
In response to Re: Nested transactions and tuple header info  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: Nested transactions and tuple header info  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I said

> One such possible caller is EvalPlanQual.  It could go to sleep using
> XactLockTableWait() on the SnapshotDirty's xmax.  But the tuple has
> something strange in its xmax -- it's the tuple's cmin actually.
> Leaving this would be probably a bug.
> 
> However, if the tuple is new, then EvalPlanQual won't even try to see
> it.  Or maybe it will.  And then, maybe there are other callers (I can
> only see _bt_check_unique).

Right, this is a worse problem than I thought :-(  I can't get past
initdb because _bt_check_unique calls XactLockTableWait() with it's own
Xid, which we refuse.  Actually not it's own Xid, but the phantom Xid
that was just assigned to some tuple, in the same transaction.

Not sure how to fix this -- I'm not even sure what the exact problem is,
because it's trying to insert the oid of a toast table in
pg_class_oid_index during the first ALTER TABLE ... CREATE TOAST TABLE.
Why would it see an old tuple with the same value, I don't know.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Always assume the user will do much worse than the stupidest thing
you can imagine."                                (Julien PUYDT)



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: Release 7.4.3 branded
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: [COMMITTERS] pgsql-server: Clean up generation of