Transactional enum additions - was Re: Alter or rename enum value
От | Andrew Dunstan |
---|---|
Тема | Transactional enum additions - was Re: Alter or rename enum value |
Дата | |
Msg-id | 56FFE757.1090301@dunslane.net обсуждение исходный текст |
Ответ на | Re: Alter or rename enum value (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Transactional enum additions - was Re: Alter or rename enum value
|
Список | 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
В списке pgsql-hackers по дате отправления: