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 | 28297.1341173928@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: XX000: enum value 117721 not found in cache for enum enumcrash (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: XX000: enum value 117721 not found in cache for enum enumcrash
|
Список | pgsql-hackers |
I wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> I think the problem is that load_enum_cache_data() uses >> GetTransactionSnapshot() rather than GetLatestSnapshot(). > That would only make the race condition window smaller (ie, hard > to reproduce manually like this, but not gone). No, wait, we made ALTER TYPE ADD VALUE PreventTransactionChain so that uncommitted enum OIDs could never get into tables or indexes. So I think you're right, forcing a new snapshot to be used would fix this. However, I'm a bit worried by the "if (!FirstSnapshotSet)" restriction in GetLatestSnapshot. Are we sure that enum comparisons could never happen without a snapshot already being set? What's the point of throwing an error there anyway, as opposed to letting it redirect to GetTransactionSnapshot? regards, tom lane
В списке pgsql-hackers по дате отправления: