Re: [ADMIN] Problems with enums after pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [ADMIN] Problems with enums after pg_upgrade
Дата
Msg-id 17203.1355934695@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [ADMIN] Problems with enums after pg_upgrade  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: [ADMIN] Problems with enums after pg_upgrade  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote:
>> Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more
>> or less changed enum_add and enum_del (Which are appended at the end) to be
>> able to change enums within transactions.

> That explains everything. You *CANNOT* do that.

Yeah.  So this was not pg_upgrade's fault at all: that code would have
created problems in 9.1 or later even without using pg_upgrade.

For the record, the reason you can't safely do this is exactly what we
saw here: it's possible for deleted/never-committed values of the type
to remain behind in upper levels of btree indexes.  Since we now need
to be able to consult pg_enum to know how to compare values of an enum
type, deleted values are uncomparable.

enum_add is all right as long as you are careful to commit its
transaction before inserting the new value anywhere.  enum_del is quite
unsafe unless you REINDEX all indexes on columns of the type after
making sure the value is gone from the tables.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Set visibility map bit after HOT prune
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: Set visibility map bit after HOT prune