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
