On 5/5/23 9:04 AM, Amit Kapila wrote:
On Fri, May 5, 2023 at 11:08 AM Drouvot, Bertrand
<[email protected]> wrote:
On 5/4/23 6:43 AM, Amit Kapila wrote:
On Thu, May 4, 2023 at 8:37 AM vignesh C <[email protected]> wrote:
Thanks for posting the updated patch, I had run this test in a loop of
100 times to verify that there was no failure because of race
conditions. The 100 times execution passed successfully.
One suggestion:
"wal file" should be changed to "WAL file":
+# Request a checkpoint on the standby to trigger the WAL file(s) removal
+$node_standby->safe_psql('postgres', 'checkpoint;');
+
+# Verify that the wal file has not been retained on the standby
+my $standby_walfile = $node_standby->data_dir . '/pg_wal/' . $walfile_name;
Thanks for the verification. I have pushed the patch.
It looks like there is still something wrong with this test as there
are a bunch of cfbot errors on this new test (mainly on macOS - Ventura -
Meson).
Is it possible for you to point me to those failures?
I'll try to reproduce with more debug infos.
Okay, thanks!
After multiple attempts, I got one failing one.
Issue is that we expect this file to be removed:
[07:24:27.261](0.899s) #WAL file is
/Users/admin/pgsql/build/testrun/recovery/035_standby_logical_decoding/data/t_035_standby_logical_decoding_standby_data/pgdata/pg_wal/000000010000000000000003
But the standby emits:
2023-05-05 07:24:27.216 UTC [17909][client backend]
[035_standby_logical_decoding.pl][3/6:0] LOG: statement: checkpoint;
2023-05-05 07:24:27.216 UTC [17745][checkpointer] LOG: restartpoint starting:
immediate wait
2023-05-05 07:24:27.259 UTC [17745][checkpointer] LOG: attempting to remove
WAL segments older than log file 000000000000000000000002
So it seems the test is not right (missing activity??), not sure why yet.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
