From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Transactional sequence stuff breaks pg_upgrade
Date: Mon, 12 Jun 2017 17:13:34 -0400
Message-ID: <23291.1497302014@sss.pgh.pa.us> (raw)
In-Reply-To: <20170612210221.vz2u373tcwu3g624@alap3.anarazel.de>
References: <19785.1497215827@sss.pgh.pa.us>
<9761.1497225808@sss.pgh.pa.us>
<20170612210221.vz2u373tcwu3g624@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Andres Freund <andres@anarazel.de> writes:
> On 2017-06-11 20:03:28 -0400, Tom Lane wrote:
>> @@ -391,6 +391,13 @@ GetNewRelFileNode(Oid reltablespace, Rel
>> bool collides;
>> BackendId backend;
>>
>> + /*
>> + * If we ever get here during pg_upgrade, there's something wrong; all
>> + * relfilenode assignments during a binary-upgrade run should be
>> + * determined by commands in the dump script.
>> + */
>> + Assert(!IsBinaryUpgrade);
>> +
> I'm very doubtful that a) this doesn't get hit in practice, and b) that
> we can rely on it going forward. At least until we change toasting to
> not use the global oid counter.
This is not about assignments from the global OID counter; the function
it's touching is GetNewRelFileNode() not GetNewObjectId().
GetNewObjectId() definitely does get hit during a binary-upgrade restore,
for all object types that pg_upgrade doesn't try to control the OIDs of
--- which is most. We don't care, for the most part. But we *do* care
about relfilenode assignments, for precisely the reason seen in this bug.
*All* assignments of relfilenodes have to be shortcircuited by pg_upgrade
override calls during a binary-restore run, or we risk filename
collisions. So if this assert ever gets hit, we have something to fix.
I intend to not only commit this, but back-patch it. There's enough
changes in relevant code paths that logic that is fine in HEAD might
not be fine in back branches.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, peter.eisentraut@2ndquadrant.com
Subject: Re: Transactional sequence stuff breaks pg_upgrade
In-Reply-To: <23291.1497302014@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox