Re: XX000: enum value 117721 not found in cache for enum enumcrash - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: XX000: enum value 117721 not found in cache for enum enumcrash
Date
Msg-id 1341205369-sup-8188@alvh.no-ip.org
Whole thread Raw
In response to Re: XX000: enum value 117721 not found in cache for enum enumcrash  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Excerpts from Tom Lane's message of lun jul 02 00:24:06 -0400 2012:
> 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.

Yeah, that's correct.  I guess I could have made the check an Assert()
instead of elog().

> 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).

Sounds sensible.

> 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.

I think it should work fine as long as the snapshot is registered, but
as you say it is untested.  Maybe it'd have interactions with the way
snapshots connect with resource owners.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: XX000: enum value 117721 not found in cache for enum enumcrash
Next
From: Pavel Stehule
Date:
Subject: autocomplete - SELECT fx