Subject: Re: Alter or rename enum value
To: Tom Lane <tgl@sss.pgh.pa.us>
References: 
 <CAO=2mx6uvgPaPDf-rHqG8=1MZnGyVDMQeh8zS4euRyyg4D35OQ@mail.gmail.com>
 <56E049CC.8010201@dunslane.net> <25605.1457539654@sss.pgh.pa.us>
 <56E05635.70908@dunslane.net> <28167.1457543612@sss.pgh.pa.us>
 <CAO=2mx4rQHRvifT2yUQ1rz90A=9CVz4_Z0Sx1wTgwgQRzAimpQ@mail.gmail.com>
 <CAO=2mx6rK_h4BC7y+3Nu-8fuZJXdFjd9FE_MZnzkH+vnMp0C-Q@mail.gmail.com>
 <d8ja8ln7nl0.fsf@dalvik.ping.uio.no> <d8j60wb7na4.fsf@dalvik.ping.uio.no>
 <CAO=2mx6CgQXFJYXOpr4OJO+r8WX6PzEU5aT+K0vV94G7DxVJ0A@mail.gmail.com>
 <56F49CF8.8050007@BlueTreble.com> <27476.1458876456@sss.pgh.pa.us>
 <CAO=2mx6EOh6uQQ57Kv2z0x=kuyVbkEbwiY8R2h6VCPL=Fxe5wg@mail.gmail.com>
 <56F58876.6020508@dunslane.net>
 <CAKFQuwZeVdo=qQy-WV_hfqy0Wsit9tuhtZOLsq1Jx82eKc8bfQ@mail.gmail.com>
 <56F6827F.9040104@dunslane.net> <3202.1459002341@sss.pgh.pa.us>
 <56F69F5C.1060408@dunslane.net>
 <B9E6AF60-A402-4388-BE5A-BD078F3A3155@thebuild.com>
 <56F7D8BF.5000000@dunslane.net> <4075.1459088427@sss.pgh.pa.us>
Cc: Christophe Pettus <xof@thebuild.com>,
 "David G. Johnston" <david.g.johnston@gmail.com>,
 Matthias Kurz <m.kurz@irregular.at>, Jim Nasby <Jim.Nasby@bluetreble.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
From: Andrew Dunstan <andrew@dunslane.net>
Message-ID: <56FAEBEF.3080406@dunslane.net>
Date: Tue, 29 Mar 2016 16:56:15 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <4075.1459088427@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


On 03/27/2016 10:20 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> The more I think about this the more I bump up against the fact that
>> almost anything we do might want to do to ameliorate the situation is
>> going to be rolled back. The only approach I can think of that doesn't
>> suffer from this is to abort if an insert/update will affect an index on
>> a modified enum. i.e. we prevent the possible corruption from happening
>> in the first place, as we do now, but in a much more fine grained way.
> Perhaps, instead of forbidding ALTER ENUM ADD in a transaction, we could
> allow that, but not allow the new value to be *used* until it's committed?
> This could be checked cheaply during enum value lookup (ie, is xmin of the
> pg_enum row committed).
>
> What you really need is to prevent the new value from being inserted
> into any indexes, but checking that directly seems far more difficult,
> ugly, and expensive than the above.
>
> I do not know whether this would be a meaningful improvement for
> common use-cases, though.  (It'd help if people were more specific
> about the use-cases they need to work.)
>
> 			


I think this is a pretty promising approach, certainly well worth 
putting some resources into investigating. One thing I like about it is 
that it gives a nice cheap negative test, so we know if the xmin is 
committed we are safe. So we could start by rejecting anything where 
it's not, but later might adopt a more refined but expensive tests for 
cases where it isn't committed without imposing a penalty on anything else.

cheers

andrew


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers