On Sat, Jun 30, 2012 at 5:51 AM, Andres Freund <and...@2ndquadrant.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
