Transactional enum additions - was Re: Alter or rename enum value

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@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>
Date: 2016-04-02T15:37:59Z
Lists: pgsql-hackers

On 03/29/2016 04:56 PM, Andrew Dunstan wrote:
>
>
> 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.
>
>


Looking at this briefly. It looks like the check should be called from 
enum_in() and enum_recv(). What error should be raised if the enum row's 
xmin isn't committed? ERRCODE_FEATURE_NOT_SUPPORTED? or maybe 
ERRCODE_DATA_EXCEPTION? I don't see anything that fits very well.

cheers

andrew





Commits

  1. Relax transactional restrictions on ALTER TYPE ... ADD VALUE (redux).

  2. Partially restore comments discussing enum renumbering hazards.

  3. Allow adding values to an enum type created in the current transaction.