RE: A failure in t/038_save_logical_slots_shutdown.pl
Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Amit Kapila' <amit.kapila16@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-01-16T06:43:04Z
Lists: pgsql-hackers
Dear Amit, Bharath, > This is a more strict check because it is possible that even if the > latest confirmed_flush location is not persisted there is no > meaningful decodable WAL between whatever the last confirmed_flush > location saved on disk and the shutdown_checkpoint record. > Kuroda-San/Vignesh, do you have any suggestion on this one? I think it should be as testcase explicitly. There are two reasons: * e0b2eed is a commit for backend codes, so it should be tested by src/test/* files. Each src/bin/XXX/*.pl files should test only their executable. * Assuming that the feature would be broken. In this case 003_logical_slots.pl would fail, but we do not have a way to recognize on the build farm. 038_save_logical_slots_shutdown.pl helps to distinguish the case. Based on that, I think it is OK to add advance_wal() and comments, like Bharath's patch. Best Regards, Hayato Kuroda FUJITSU LIMITED
Commits
-
Fix a random failure in 038_save_logical_slots_shutdown.pl.
- 0b84f5c419a3 17.0 landed
-
Flush logical slots to disk during a shutdown checkpoint if required.
- e0b2eed047df 17.0 cited