On 03/27/2016 10:20 AM, Tom Lane wrote:
Andrew Dunstan <and...@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
