On Fri, Jul 29, 2022 at 5:13 PM Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jul 29, 2022 at 4:00 PM Tom Lane <t...@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
