| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Bernhard Schrader <bernhard(dot)schrader(at)innogames(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [ADMIN] Problems with enums after pg_upgrade |
| Date: | 2012-12-19 16:09:00 |
| Message-ID: | 50D1E69C.7070209@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-12-19 16:21:38 | Re: Set visibility map bit after HOT prune |
| Previous Message | Heikki Linnakangas | 2012-12-19 16:00:19 | ThisTimeLineID in checkpointer and bgwriter processes |