Hi,
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.
Do we consider that something that needs to be fixed or just something to
document? I can't think of a non-intrusive fix right now.
Greetings,
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
