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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christophe Pettus <xof(at)thebuild(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Matthias Kurz <m(dot)kurz(at)irregular(dot)at>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Transactional enum additions - was Re: Alter or rename enum value
Date: 2016-04-02 15:37:59
Views: Raw Message | Whole Thread | Download mbox | Resend email
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(at)dunslane(dot)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.



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-04-02 16:37:53 Re: More stable query plans via more predictable column statistics
Previous Message Stephen Frost 2016-04-02 15:12:51 Re: Small typo in a comment in pg_regress.c