Horton
Menu

Re: Logical replication launcher did not automatically restart when got SIGKILL

shveta malik <shveta.malik@gmail.com>

View thread
From: shveta malik <shveta.malik@gmail.com>
To: cca5507 <cca5507@qq.com>
Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>, shveta malik <shveta.malik@gmail.com>
Date: 2025-07-15T10:34:26Z
Lists: pgsql-hackers 
On Tue, Jul 15, 2025 at 2:56 PM cca5507 <cca5507@qq.com> wrote:
>
> Hi, hackers
>
> I found the $SUBJECT, the main reason is that RegisteredBgWorker::rw_pid has not been cleaned.
>
> Attach a patch to fix it.
>

Thank You for reporting this. The problem exists and the patch works
as expected.

In the patch, we are resetting the PID during shared memory
initialization. Is there a better place to handle PID reset in the
case of a SIGKILL, possibly within a cleanup flow? For example, during
a regular shutdown, we reset the launcher (background worker) PID in
CleanupBackend(). Or is this the only possibility?

thanks
Shveta

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add regression test for background worker restart after crash.

  2. Fix background worker not restarting after crash-and-restart cycle.

  3. Refactor code to handle death of a backend or bgworker in postmaster