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 →
-
In pg_upgrade, dump each database separately and use
- 12ee6ec71f87 9.3.0 cited