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

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: XX000: enum value 117721 not found in cache for enum enumcrash
Date: 2012-07-01 17:20:42
Message-ID: CA+TgmobbSjEWb_64FYqizdhJ8ApczOP4O12-OxpSXOBSTuFKBA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Jun 30, 2012 at 5:51 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Currently its possible to cause transactions to fail with ALTER ENUM ADD
> AFTER/BEFORE:
>
> psql 1:
>
> CREATE TYPE enumcrash AS ENUM('a', 'b');
> CREATE FUNCTION randenum() RETURNS enumcrash LANGUAGE sql AS $$SELECT * FROM
> unnest(enum_range('a'::enumcrash)) ORDER BY random() LIMIT 1$$;
> CREATE TABLE enumcrash_table(id serial primary key, val enumcrash);
> CREATE INDEX enumcrash_table__val__id ON enumcrash_table (val, id);
> INSERT INTO enumcrash_table (val) SELECT randenum() FROM generate_series(1,
> 10000);INSERT 0 10000
>
> psql 2:
> BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
> INSERT INTO enumcrash_table (val) SELECT randenum() FROM generate_series(1,
> 10000);
>
> psql 1:
> ALTER TYPE enumcrash ADD VALUE 'a_1' AFTER 'a';
> INSERT INTO enumcrash_table (val) SELECT randenum() FROM generate_series(1,
> 10000);
>
> psql 2:
> INSERT INTO enumcrash_table (val) SELECT randenum() FROM generate_series(1,
> 10000);
> ERROR:  XX000: enum value 117745 not found in cache for enum enumcrash
> LOCATION:  compare_values_of_enum, typcache.c:957
>
> This is not surprising. psql 2's backend finds rows in the index with enum
> values that are not visible in its mvcc snapshot. That mvcc snapshot is needed
> because a_1 is an enum value with an uneven numbered oid because its inserted
> after the initial creation.

I think the problem is that load_enum_cache_data() uses
GetTransactionSnapshot() rather than GetLatestSnapshot().

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-07-01 18:25:25
Subject: Re: Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux
Previous:From: Fujii MasaoDate: 2012-07-01 17:14:25
Subject: Re: [ADMIN] pg_basebackup blocking all queries with horrible performance

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