Re: WIP: extensible enums

On 10/17/2010 03:17 PM, Tom Lane wrote:
> Dean Rasheed<dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
>> On 17 October 2010 18:53, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> We could fix that with Dean's idea of reloading the cache whenever
>>> we see that we are being asked to compare a value we don't have in the
>>> cache entry. However, that assumes that we even notice that it's not
>>> in the cache entry. If we're trying to use "fast" comparison then we
>>> wouldn't notice that.
>> That makes me think maybe the "fast" and "slow" comparisons should
>> both be done the same way, having a cache so that we notice
>> immediately if we get a new value.
> Actually ... the race conditions can be a lot worse than just a race.
> Consider
>
> begin;
> alter type myenum add 'some-value';
> insert into mytab values('some-value');
> rollback;
>
> If mytab has an index on the enum col, we now have an index entry that
> contains an enum value that isn't valid according to anybody, and nobody
> knows how to compare it. If that entry is near the root then the index
> is hopelessly corrupt: no one can tell which way to descend when
> comparing it to some valid value.
>
> I think what this says is that we cannot allow any manipulations that
> involve an uncommitted enum value. Probably the easiest way is to make
> the ALTER TYPE operation disallowed-inside-transaction-block. That's
> pretty ugly, but doesn't seem like a serious restriction in practice
> (though for example it'd mean we couldn't use it in pg_dump).

Even in binary upgrade mode?

cheers

andrew