Re: --single-transaction hack to pg_upgrade does not work

On 2012-12-01 12:01:17 -0500, Andrew Dunstan wrote:
>
> On 12/01/2012 11:38 AM, Andres Freund wrote:
> >On 2012-12-01 17:36:20 +0100, Andres Freund wrote:
> >>On 2012-12-01 17:03:03 +0100, Andres Freund wrote:
> >>>Could we possibly allow adding enum values to a type which was just created in
> >>>this transaction? That shouldn't be too hard. At least easier than providing
> >>>the capability to pre-assign the next N oids...
> >>The attached patch does just that. Its *not* ready yet though, as it
> >>will be apparent for everyone who reads it ;)
> >>
> >>To really make that work in a reliable manner we would probably need
> >>an rd_createSubid for typcache entries instead of testing xmin as I have
> >>done here?
>
>
> Does this actually get you over the problem identified in the comment?:
>
>  * We disallow this in transaction blocks, because we can't cope
>  * with enum OID values getting into indexes and then having their
>  * defining pg_enum entries go away.

I don't see why not at least. No index that can contain values from the enum
will survive a transaction abort or can be seen from the outside before it
committed.

So I don't see a problem. What made you concerned?

Greetings,

Andres Freund

--Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services