Justin Pryzby <pry...@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 <br...@momjian.us> wrote:
>>> Uh, that initdb-created pg_largeobject file should not have any data in
>>> it ever, as far as I know at that point in pg_upgrade. How would values
>>> have gotten in there? Via pg_dump?
>> I was thinking if the user had done it manually before running pg_upgrade.
> 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 work
> between initdb and pg_upgrade by checking that no objects have *ever* been
> created in the new cluster, by checking that NextOid == 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
