Re: XX000: enum value 117721 not found in cache for enum enumcrash
От | Tom Lane |
---|---|
Тема | Re: XX000: enum value 117721 not found in cache for enum enumcrash |
Дата | |
Msg-id | 21993.1341203046@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: XX000: enum value 117721 not found in cache for enum enumcrash (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: XX000: enum value 117721 not found in cache for enum enumcrash
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Jul 2, 2012, at 12:04 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Jul 1, 2012, at 4:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> However, I'm a bit worried by the "if (!FirstSnapshotSet)" restriction >>> in GetLatestSnapshot. >> I don't know whether it should set the transaction snapshot or just r > Argh, sorry. > ...or just return a current snapshot, and I also don't know whether it needs to be changed because of this; but I agreewith changing it. Erroring out always seemed kind of pointless to me... I think it was coded like that because the sole original use was in ri_triggers.c, in which it would have been a red flag if no transaction snapshot already existed. However, the restriction clearly doesn't fit with GetLatestSnapshot's API spec, so it seems to me to be sensible to change it (as opposed to, say, inventing a new snapshot function with a subtly different API spec). As for creating an MVCC snapshot without causing a transaction snapshot to be established, no thanks --- that would create a path of control that exists nowhere today and has gotten no testing at all. I suspect that it might actively break some assumptions in snapshot management. regards, tom lane
В списке pgsql-hackers по дате отправления: