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:35:37 -0400
Message-ID: <11213.1497303337@sss.pgh.pa.us> (raw)
In-Reply-To: <20170612212517.j3xe6am7hlztl6fw@alap3.anarazel.de>
References: <19785.1497215827@sss.pgh.pa.us>
<9761.1497225808@sss.pgh.pa.us>
<20170612210221.vz2u373tcwu3g624@alap3.anarazel.de>
<23291.1497302014@sss.pgh.pa.us>
<20170612212517.j3xe6am7hlztl6fw@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Andres Freund <andres@anarazel.de> writes:
> In my opinion the problem of:
> On 2017-06-12 17:13:34 -0400, Tom Lane wrote:
>> assignments of relfilenodes have to be shortcircuited by pg_upgrade
>> override calls during a binary-restore run, or we risk filename
>> collisions.
> should instead be solved by simply not even trying to preserve
> relfilenodes. We can "just" copy/link files to the the new
> relfilenodes, there's no need to preserve them, in contrast to
> pg_class.oid etc. But that's obviously something for the future.
Right. But until somebody gets around to fixing that, it's a problem.
Also, even if we fix this, we still have the issue of type OIDs residing
on-disk in places like array headers; that results in pg_upgrade having
to control type OID assignments as well. I thought about trying to insert
an assert in GetNewOidWithIndex to ensure that no type OIDs are selected
automatically during upgrade, but it seemed a bit too complicated. Might
be a good idea to figure it out though, unless you have an idea for
removing that requirement.
>> 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.
> Hm.
Just found out that 9.4 (and probably older) fail the assertion because
of the temp table created in get_rel_infos(). That's *probably* all
right because the table is *probably* gone from disk by the time we
start the actual restore run. But we start the new postmaster only
once, with -b, so the assertion applies to the preparatory steps as
well as the restore proper.
Later versions avoid that by using a CTE instead of a temp table.
I'm not excited enough about this to back-port the patch that
changed it, so I'm thinking of just adding the assert back to 9.5.
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: <11213.1497303337@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