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

From Robert Haas
Subject Re: pg15b2: large objects lost on upgrade
Date
Msg-id CA+TgmoZX6Zz4KU2enOYyc+aQWA+S5ZaZRGo6BgxW7mNF4btqaw@mail.gmail.com
Whole thread Raw
In response to Re: pg15b2: large objects lost on upgrade  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg15b2: large objects lost on upgrade
List pgsql-hackers
On Fri, Jul 29, 2022 at 5:13 PM Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jul 29, 2022 at 4:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Looks plausible.
>
> Committed.

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. That said, perhaps this is just a case of needing to
prevent autovacuum from running on the new cluster before we've had a
chance to record the horizons? But I'm not very confident in that
explanation at this point.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg15b2: large objects lost on upgrade
Next
From: Tom Lane
Date:
Subject: Re: Trying to add more tests to gistbuild.c