Re: 030_pg_recvlogical fails because the same PID is assigned

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: 030_pg_recvlogical fails because the same PID is assigned
Date: 2026-08-03 15:24:53
Message-ID: CAHGQGwFSOT0kw4yzt7YzoKbK+4om1X=HJBxXXt5aoyr-JBETuA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 31, 2026 at 6:12 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> BTW, here is a patch to fix the issue.

Thanks for the patch!

+$node->wait_for_log(
+ qr/START_REPLICATION SLOT \"reconnect_test\" LOGICAL/,
+ $log_offset);

Could this pattern also match the STATEMENT log entry emitted when
the old walsender is terminated by pg_terminate_backend()? If so,
is it be better to wait for the new slot acquisition instead? For example:

qr/acquired logical replication slot \"reconnect_test\"/,

Regards,

--
Fujii Masao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2026-08-03 17:17:07 Re: CREATE SUBSCRIPTION ... SERVER vs. pg_dump, etc.
Previous Message Kevin Rocker 2026-08-03 15:20:59 Re: [PATCH] Fix vacuum_delay_point happening inside lock