From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Transactional sequence stuff breaks pg_upgrade
Date: Tue, 13 Jun 2017 09:37:59 -0400
Message-ID: <32233.1497361079@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmobZhwAOwudbXaEB0WQ8C-qL9kPCGDUsu3EMY_VhDDY7zg@mail.gmail.com>
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>
<CA+TgmobZhwAOwudbXaEB0WQ8C-qL9kPCGDUsu3EMY_VhDDY7zg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Robert Haas <robertmhaas@gmail.com> writes:
> The problem is that if a relfilenode ever gets assigned by
> GetNewRelFileNode() during a binary-upgrade restore, that OID may turn
> out to be used by some other object later in the dump. And then
> you're dead, because the dump restore will fail later on complaining
> about, well, I forget the error message wording exactly, but,
> basically, an OID collision.
Right.
> So if we change the rules in such a way
> that objects which currently lack TOAST tables acquire them, we need
> to first restore all of the objects *without* adding any new TOAST
> tables, and then at the end create any new TOAST tables once we have a
> complete list of the relfilenodes that are actually used.
toasting.c explains why this currently doesn't seem necessary:
/*
* In binary-upgrade mode, create a TOAST table if and only if
* pg_upgrade told us to (ie, a TOAST table OID has been provided).
*
* This indicates that the old cluster had a TOAST table for the
* current table. We must create a TOAST table to receive the old
* TOAST file, even if the table seems not to need one.
*
* Contrariwise, if the old cluster did not have a TOAST table, we
* should be able to get along without one even if the new version's
* needs_toast_table rules suggest we should have one. There is a lot
* of daylight between where we will create a TOAST table and where
* one is really necessary to avoid failures, so small cross-version
* differences in the when-to-create heuristic shouldn't be a problem.
* If we tried to create a TOAST table anyway, we would have the
* problem that it might take up an OID that will conflict with some
* old-cluster table we haven't seen yet.
*/
I don't really see any near-term reason why we would need to change this.
In the long run, it would certainly be cleaner if pg_upgrade dropped
the force-the-relfilenode-assignment approach and instead remapped
relfilenodes from old cluster to new. But I think it's just for
cleanliness rather to fix any live or foreseeable bug.
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, robertmhaas@gmail.com, andres@anarazel.de, peter.eisentraut@2ndquadrant.com
Subject: Re: Transactional sequence stuff breaks pg_upgrade
In-Reply-To: <32233.1497361079@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