Re: XX000: enum value 117721 not found in cache for enum enumcrash

Excerpts from Tom Lane's message of lun jul 02 00:24:06 -0400 2012:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Jul 2, 2012, at 12:04 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >> On Jul 1, 2012, at 4:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 agree with 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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support