Re: pg15b2: large objects lost on upgrade
От | Noah Misch |
---|---|
Тема | Re: pg15b2: large objects lost on upgrade |
Дата | |
Msg-id | 20220730054401.GB3644221@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: pg15b2: large objects lost on upgrade (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg15b2: large objects lost on upgrade
|
Список | 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 по дате отправления: