Thread: recoveryCheck test failure on flaviventris
I noticed this recoveryCheck test failure on flaviventris after pushing commit 3b35f9a4c (Fix an incorrect check in get_memoize_path). ### Reloading node "standby" # Running: pg_ctl --pgdata xxx/pgdata reload server signaled ### Restarting node "standby" # Running: pg_ctl --wait --pgdata xxx/pgdata --log xxx.log restart waiting for server to shut down ... failed pg_ctl: server does not shut down # pg_ctl restart failed; see logfile for details: xxx.log # Postmaster PID for node "standby" is 63577 [02:09:29.767](364.847s) Bail out! pg_ctl restart failed I'm not convinced this failure is related to 3b35f9a4c; it seems unlikely that just changing how Memoize paths are created would cause it. Does anyone have any insights into what might be going on? Thanks Richard
On Wed, Apr 16, 2025 at 11:54 AM Richard Guo <guofenglinux@gmail.com> wrote: > I noticed this recoveryCheck test failure on flaviventris after > pushing commit 3b35f9a4c (Fix an incorrect check in get_memoize_path). > > ### Reloading node "standby" > # Running: pg_ctl --pgdata xxx/pgdata reload > server signaled > ### Restarting node "standby" > # Running: pg_ctl --wait --pgdata xxx/pgdata --log xxx.log restart > waiting for server to shut down ... failed > pg_ctl: server does not shut down > # pg_ctl restart failed; see logfile for details: xxx.log > # Postmaster PID for node "standby" is 63577 > [02:09:29.767](364.847s) Bail out! pg_ctl restart failed > > I'm not convinced this failure is related to 3b35f9a4c; it seems > unlikely that just changing how Memoize paths are created would cause > it. > > Does anyone have any insights into what might be going on? Forgot to include the link to the failure. Here it is: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2025-04-16%2001%3A58%3A42 Thanks Richard
Hello Richard,
16.04.2025 06:05, Richard Guo wrote:
16.04.2025 06:05, Richard Guo wrote:
On Wed, Apr 16, 2025 at 11:54 AM Richard Guo <guofenglinux@gmail.com> wrote:I noticed this recoveryCheck test failure on flaviventris after pushing commit 3b35f9a4c (Fix an incorrect check in get_memoize_path). ... I'm not convinced this failure is related to 3b35f9a4c; it seems unlikely that just changing how Memoize paths are created would cause it. Does anyone have any insights into what might be going on?Forgot to include the link to the failure. Here it is: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2025-04-16%2001%3A58%3A42
Judging by:
### Restarting node "standby"
# Running: pg_ctl --wait --pgdata /home/bf/bf-build/flaviventris/HEAD/pgsql.build/testrun/recovery/035_standby_logical_decoding/data/t_035_standby_logical_decoding_standby_data/pgdata --log /home/bf/bf-build/flaviventris/HEAD/pgsql.build/testrun/recovery/035_standby_logical_decoding/log/035_standby_logical_decoding_standby.log restart
waiting for server to shut down........................................................................................................................................................................................................................................................................................................................................................................... failed
pg_ctl: server does not shut down
I think it's a known issue:
https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#001_rep_changes.pl_fails_due_to_publisher_stuck_on_shutdown
and is not related to the Memoize paths.
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
On Wed, Apr 16, 2025 at 1:00 PM Alexander Lakhin <exclusion@gmail.com> wrote: > 16.04.2025 06:05, Richard Guo wrote: > On Wed, Apr 16, 2025 at 11:54 AM Richard Guo <guofenglinux@gmail.com> wrote: > I noticed this recoveryCheck test failure on flaviventris after > pushing commit 3b35f9a4c (Fix an incorrect check in get_memoize_path). > ... > I'm not convinced this failure is related to 3b35f9a4c; it seems > unlikely that just changing how Memoize paths are created would cause > it. > > Does anyone have any insights into what might be going on? > Forgot to include the link to the failure. Here it is: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2025-04-16%2001%3A58%3A42 > Judging by: > ### Restarting node "standby" > # Running: pg_ctl --wait --pgdata /home/bf/bf-build/flaviventris/HEAD/pgsql.build/testrun/recovery/035_standby_logical_decoding/data/t_035_standby_logical_decoding_standby_data/pgdata --log /home/bf/bf-build/flaviventris/HEAD/pgsql.build/testrun/recovery/035_standby_logical_decoding/log/035_standby_logical_decoding_standby.log restart > waiting for server to shut down........................................................................................................................................................................................................................................................................................................................................................................... failed > pg_ctl: server does not shut down > > I think it's a known issue: > https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#001_rep_changes.pl_fails_due_to_publisher_stuck_on_shutdown > and is not related to the Memoize paths. Got it. Thanks for the information. Thanks Richard
Dear Richard, Alexander, FYI - I felt there is a same type of failure [1] for REL_17_STABLE, added in the wikipage. Feel free to revert it if I did something wrong. [1]: https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=prion&dt=2025-04-15%2016%3A16%3A06&stg=recovery-check Best regards, Hayato Kuroda FUJITSU LIMITED
Dear Kuroda-san,
16.04.2025 11:12, Hayato Kuroda (Fujitsu) wrote:
16.04.2025 11:12, Hayato Kuroda (Fujitsu) wrote:
Dear Richard, Alexander, FYI - I felt there is a same type of failure [1] for REL_17_STABLE, added in the wikipage. Feel free to revert it if I did something wrong. [1]: https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=prion&dt=2025-04-15%2016%3A16%3A06&stg=recovery-check
Thank you for adding that! (I'm a bit slow on analyzing new failures, but
I hope I could catch up on the weekend.)
I've just reformatted the record to match my script's [1] expectations.
[1] https://www.postgresql.org/message-id/b62f97b1-bbff-42cd-861f-c785f0774ab8%40gmail.com
Best regards,
Alexander Lakhin
Neon (https://neon.tech)