Re: pg15b2: large objects lost on upgrade - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg15b2: large objects lost on upgrade
Date
Msg-id Yr+4vXIAG6E8evva@paquier.xyz
Whole thread Raw
In response to pg15b2: large objects lost on upgrade  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Fri, Jul 01, 2022 at 06:14:13PM -0500, Justin Pryzby wrote:
> I reproduced the problem at 9a974cbcba but not its parent commit.
>
> commit 9a974cbcba005256a19991203583a94b4f9a21a9
> Author: Robert Haas <rhaas@postgresql.org>
> Date:   Mon Jan 17 13:32:44 2022 -0500
>
>     pg_upgrade: Preserve relfilenodes and tablespace OIDs.

Oops.  Robert?

This reproduces as well when using pg_upgrade with the same version as
origin and target, meaning that this extra step in the TAP test is
able to reproduce the issue (extra VACUUM FULL before chdir'ing):
--- a/src/bin/pg_upgrade/t/002_pg_upgrade.pl
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -208,6 +208,8 @@ if (defined($ENV{oldinstall}))
    }
 }

+$oldnode->safe_psql("regression", "VACUUM FULL pg_largeobject;");
+
# In a VPATH build, we'll be started in the source directory, but we want
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Time to remove unparenthesized syntax for VACUUM?
Next
From: Amit Kapila
Date:
Subject: Re: Support logical replication of DDLs