Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: XX000: enum value 117721 not found in cache for enum enumcrash
Date: 2012-07-01 20:18:48
Message-ID: 28297.1341173928@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Jeff JanesDate: 2012-07-01 20:25:27
Subject: Re: Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux
Previous:From: Tom LaneDate: 2012-07-01 19:59:08
Subject: Re: XX000: enum value 117721 not found in cache for enum enumcrash

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group