Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during promotion?

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>
Cc: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during promotion?
Date: 2026-04-02 05:01:37
Message-ID: CAHGQGwHndKa--mCKAaSpAtdTte_3RJkUueZcDSqdUASqTsDK0Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 1, 2026 at 8:11 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
> > As for backpatching, this looks like it should go back to v17, where slotsync
> > was introduced. Thought?
>
> Right, the issue exists in v17 as well.
>
> Attached the updated patch.

Thanks for updating the patch! LGTM.

I noticed that commit 1362bc33e02 updated the slotsync code so that a backend
performing slot synchronization is signaled on promotion, but it was applied
only to master. I’m not sure why it wasn’t backpatched to v17 and v18,
but it seems we need to backpatch it first before backpatching this patch.
Thought?

I've prepared patches for v18 and v17 and attached them. For the patch for
master, I only updated the commit message. For v18 and v17,
commit 1362bc33e02 needs to be applied first.

I haven't tested the v18 and v17 patches yet. I'll do that next.

Regards,

--
Fujii Masao

Attachment Content-Type Size
v9-0001-pg17-Fix-slotsync-worker-blocking-promotion-when-stuck.txt text/plain 11.5 KB
v9-0001-pg18-Fix-slotsync-worker-blocking-promotion-when-stuck.txt text/plain 11.6 KB
v9-0001-Fix-slotsync-worker-blocking-promotion-when-stuck.patch application/octet-stream 12.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-04-02 05:28:24 Re: Initial COPY of Logical Replication is too slow
Previous Message Tom Lane 2026-04-02 04:26:42 Re: LLVM 22