RE: [PoC] pg_upgrade: allow to upgrade publisher node
Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Alexander Lakhin' <exclusion@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, Peter Smith <smithpb2250@gmail.com>, Andres Freund <andres@anarazel.de>, Dilip Kumar <dilipbalaut@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Bruce Momjian <bruce@momjian.us>, Julien Rouhaud <rjuju123@gmail.com>
Date: 2023-12-17T15:03:33Z
Lists: pgsql-hackers
Dear Thomas, Alexander, > 17.12.2023 07:02, Thomas Munro wrote: > > FYI fairywren failed in this test: > > > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2023-1 > 2-16%2022%3A03%3A06 > > > > ===8<=== > > Restoring database schemas in the new cluster > > *failure* > > > > Consult the last few lines of > > > "C:/tools/nmsys64/home/pgrunner/bf/root/HEAD/pgsql.build/testrun/pg_upgr > ade/003_logical_slots/data/t_003_logical_slots_newpub_data/pgdata/pg_upgra > de_output.d/20231216T221418.035/log/pg_upgrade_dump_1.log" > > for > > the probable cause of the failure. > > Failure, exiting > > [22:14:34.598](22.801s) not ok 10 - run of pg_upgrade of old cluster > > [22:14:34.600](0.001s) # Failed test 'run of pg_upgrade of old cluster' > > # at > C:/tools/nmsys64/home/pgrunner/bf/root/HEAD/pgsql/src/bin/pg_upgrade/t/ > 003_logical_slots.pl > > line 177. > > ===8<=== > > > > Without that log it might be hard to figure out what went wrong though :-/ > > > > Yes, but most probably it's the same failure as > Thanks for reporting. Yes, it has been already reported by me [1], and the server log was provided by Andrew [2]. The issue was that a file creation was failed because the same one was unlink()'d just before but it was in STATUS_DELETE_PENDING status. Kindly Alexander proposed a fix [3] and it looks good to me, but confirmations by senior and windows-friendly developers are needed to move forward. (at first we thought the issue was solved by updating, but it was not correct) I know that you have developed there region, so I'm very happy if you check the forked thread. [1]: https://www.postgresql.org/message-id/flat/TYAPR01MB5866AB7FD922CE30A2565B8BF5A8A%40TYAPR01MB5866.jpnprd01.prod.outlook.com [2]: https://www.postgresql.org/message-id/TYAPR01MB5866A4E7342088E91362BEF0F5BBA%40TYAPR01MB5866.jpnprd01.prod.outlook.com [3]: https://www.postgresql.org/message-id/976479cf-dd66-ca19-f40c-5640e30700cb%40gmail.com Best Regards, Hayato Kuroda FUJITSU LIMITED
Commits
-
Fix issues in binary_upgrade_logical_slot_has_caught_up().
- 0bf62460bb9e 17.0 landed
-
Fix a random failure in 003_logical_slots.pl.
- 63c5df126abb 17.0 landed
-
Fix a test in 003_logical_slots.
- 3e36e48d8efe 17.0 landed
-
Fix uninitialized slot array access during the upgrade.
- a7db71ed2787 17.0 landed
-
Fix the test 003_logical_slots.
- 8af917be6bad 17.0 landed
-
Commit b195e6d482 forgot to update meson.build.
- 8949b978ff49 17.0 landed
-
Use shorter file names in the upgrade logical slots test.
- b195e6d482b8 17.0 landed
-
Migrate logical slots to the new node during an upgrade.
- 29d0a77fa660 17.0 landed
-
Flush logical slots to disk during a shutdown checkpoint if required.
- e0b2eed047df 17.0 landed
-
Prevent possibility of panics during shutdown checkpoint.
- c6c333436491 10.0 cited