030_pg_recvlogical fails because the same PID is assigned

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: 030_pg_recvlogical fails because the same PID is assigned
Date: 2026-07-30 14:01:13
Message-ID: OS9PR01MB121497CF10DFF54F745E37204F5C92@OS9PR01MB12149.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

There was a random buildfarm failure for 030_pg_recvlogical [1].

It tests that pg_recvlogical can re connect to the server if it the connection is
lost. And we try to ensure by motnitoring the active_pid of the pg_replication_slots
is changed.

According to the logfile in [1], the PID of the first walsender was 4360, and
pg_terminate_backend() was done toward it. But while waiting a slot was acquired
by the different process, another walsender whose PID was 4360 (!) was started
and it acquired the slot. The test finally failed because the slot was not
acquired by the different process.

Not sure, does it indicate some other issues? If no, we can wait log output like
"STATEMENT: START_REPLICATION SLOT "reconnect_test" LOGICAL"
to make the test robust.

[1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2026-07-30%2009%3A58%3A12

Best regards,
Hayato Kuroda
FUJITSU LIMITED

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2026-07-30 14:17:24 Re: Small fixes needed by high-availability tools
Previous Message Tom Lane 2026-07-30 13:50:54 Re: zic: fix PostgreSQL build failure on filesystems without hard link support