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

From Noah Misch
Subject Re: pg15b2: large objects lost on upgrade
Date
Msg-id 20220730054401.GB3644221@rfd.leadboat.com
Whole thread Raw
In response to Re: pg15b2: large objects lost on upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg15b2: large objects lost on upgrade
List pgsql-hackers
On Fri, Jul 29, 2022 at 07:16:34PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > wrasse just failed the new test:
> 
> > [00:09:44.167](0.001s) not ok 16 - old and new horizons match after pg_upgrade
> > [00:09:44.167](0.001s)
> > [00:09:44.167](0.000s) #   Failed test 'old and new horizons match
> > after pg_upgrade'
> > #   at t/002_pg_upgrade.pl line 345.
> > [00:09:44.168](0.000s) #          got: '1'
> > #     expected: '0'
> > === diff of
/export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/tmp_test_D3cJ/horizon1.txt
> > and /export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/tmp_test_D3cJ/horizon2.txt
> > === stdout ===
> > 1c1
> > < pg_backend_pid|21767
> > ---
> > > pg_backend_pid|22045=== stderr ===
> > === EOF ===
> 
> > I'm slightly befuddled as to how we're ending up with a table named
> > pg_backend_pid.

> The lack of -X and the lack of use of installed_command()
> are red flags.

The pg_backend_pid is from "SELECT pg_catalog.pg_backend_pid();" in ~/.psqlrc,
so the lack of -X caused that.  The latest commit fixes things on a normal
GNU/Linux box, so I bet it will fix wrasse.  (thorntail managed not to fail
that way.  For unrelated reasons, I override thorntail's $HOME to a
mostly-empty directory.)



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: optimize lookups in snapshot [sub]xip arrays
Next
From: Michael Paquier
Date:
Subject: Re: Inconvenience of pg_read_binary_file()