Horton
Menu

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Bruce Momjian <bruce@momjian.us>, Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@postgresql.org
Date: 2012-12-01T17:00:46Z
Lists: pgsql-hackers 
Andres Freund <andres@2ndquadrant.com> writes:
>> The attached patch does just that. Its *not* ready yet though, as it
>> will be apparent for everyone who reads it ;)

ISTM this sort of thing ought to be safe enough, though you probably
need to insist both that the pg_type row's xmin be current XID and
that it not be HEAP_UPDATED.

>> 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?

What's more reliable about that?  For one thing, cache entries can get
flushed.  The relcache goes to some lengths to hang onto rd_createSubid
anyway, but I don't want to put equivalent logic into typcache.

			regards, tom lane

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