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

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Date: 2012-12-01T17:01:17Z
Lists: pgsql-hackers
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.


cheers

andrew




Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. In pg_upgrade, dump each database separately and use