Re: Nested transactions and tuple header info

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)