From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: Robert Haas <robertmhaas@gmail.com>, Bruce Momjian <bruce@momjian.us>,
        pgsql-hackers@postgresql.org, Shruthi Gowda <gowdashru@gmail.com>
Subject: Re: pg15b2: large objects lost on upgrade
In-reply-to: <20220707184410.GB13040@telsasoft.com>
References: <20220702154917.GM13040@telsasoft.com>
 <CA+Tgmobg=5hAVCcTD2277AiuqCL0Vp38ETepuR2hAxeqSyR9kg@mail.gmail.com>
 <20220705165605.GR13040@telsasoft.com>
 <CA+TgmoY0bREBNKWFkOzpg7is3DQK7gsnMoA+bBzE9+y9kdjhng@mail.gmail.com>
 <20220706115600.GU13040@telsasoft.com>
 <CA+Tgmoavavffv2GTtZ-1=QUxZh020xfUUAOS6mXd9u_zFQ=9Qw@mail.gmail.com>
 <20220707171019.GA13040@telsasoft.com>
 <CA+TgmoZDg-osUEV5FkXiL7zuVT2=m_ABVP5W9uhaAdBRnhgJPQ@mail.gmail.com>
 <YsckxPjKlGcTB50j@momjian.us>
 <CA+TgmoaT_OMUjehQP8BvChV+5XJe3KUjiCLcad5NnvnQA5OkCA@mail.gmail.com>
 <20220707184410.GB13040@telsasoft.com>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Thu, 07 Jul 2022 13:44:10 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3032998.1657220719.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 07 Jul 2022 15:05:19 -0400
Message-ID: <3032999.1657220719@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3032999.1657220719%40sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.com> writes:
> On Thu, Jul 07, 2022 at 02:38:44PM -0400, Robert Haas wrote:
>> On Thu, Jul 7, 2022 at 2:24 PM Bruce Momjian <bruce@momjian.us> wrote:
>>> Uh, that initdb-created pg_largeobject file should not have any data i=
n
>>> it ever, as far as I know at that point in pg_upgrade.  How would valu=
es
>>> have gotten in there?  Via pg_dump?

>> I was thinking if the user had done it manually before running pg_upgra=
de.

> We're referring to the new cluster which should have been initdb'd more =
or less
> immediately before running pg_upgrade [0].

> It'd be weird to me if someone were to initdb a new cluster, then create=
 some
> large objects, and then maybe delete them, and then run pg_upgrade.

AFAIK you're voiding the warranty if you make any changes at all in the
destination cluster before pg_upgrade'ing.  As an example, if you created
a table there you'd be risking an OID and/or relfilenode collision with
something due to be imported from the source cluster.

> Actually, I think check_new_cluster_is_empty() ought to prohibit doing w=
ork
> between initdb and pg_upgrade by checking that no objects have *ever* be=
en
> created in the new cluster, by checking that NextOid =3D=3D 16384.

It would be good to have some such check; I'm not sure that that one in
particular is the best option.

> But I have a
> separate thread about "pg-upgrade allows itself to be re-run", and this =
has
> more to do with that than about whether to check that the file is empty =
before
> removing it.

Yeah, that's another foot-gun in the same area.

			regards, tom lane