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
