Re: [ADMIN] Problems with enums after pg_upgrade - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [ADMIN] Problems with enums after pg_upgrade
Date
Msg-id 50D1E69C.7070209@dunslane.net
Whole thread Raw
In response to Re: [ADMIN] Problems with enums after pg_upgrade  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 12/19/2012 10:56 AM, Andres Freund wrote:
> On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote:
>> Hello again,
>>
>> well, still everything is working.
>>
>> What information do you need to get into this issue?
>>
>> 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. There are some pretty
> fundamental reasons why you are not allowed to add enums in a
> transaction. And even more reasons why deleting from enums isn't allowed
> at all.
>


Yes, this is exactly what I referred to in my recent reply to Tom. This 
is a recipe for database corruption.

Hacking the catalog generally is something to be done only with the most 
extreme caution, IMNSHO.

cheers

andrew



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: ThisTimeLineID in checkpointer and bgwriter processes
Next
From: Tom Lane
Date:
Subject: Re: Set visibility map bit after HOT prune