Re: Nested transactions and tuple header info

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Nested transactions and tuple header info
Дата
Msg-id 20040613063238.GA26479@dcc.uchile.cl
обсуждение исходный текст
Ответ на Re: Nested transactions and tuple header info  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Ответы Re: Nested transactions and tuple header info  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: Release 7.4.3 branded
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: [COMMITTERS] pgsql-server: Clean up generation of