MIME-Version: 1.0
References: 
 <CAHGQGwFzNYroAxSoyJhqTU-pH=t4Ej6RyvhVmBZ91Exj_TPMMQ@mail.gmail.com>
 <CAA4eK1+CrQNqiPDKv1wYfdkbX0FARJoi1=0ioaAqkLzbq2vG1w@mail.gmail.com>
 <CAHGQGwHABvuCoyM24HUiFZ5oJq_CoFomjt_cqD-0cJLMjFXJjQ@mail.gmail.com>
 <CAA4eK1LzZGfRANPAnv6NpKCH2ENuZO6HswgY14A=xsOXmucPhw@mail.gmail.com>
 <CABdArM6nepct0uxizCnZqy-kAjjTOndvu7bWtaNcmknuxx82Hg@mail.gmail.com>
 <CAJpy0uBhJB4HqouLXegD=miSkZfZp86tTC2K0K6nf=bHCcsPLQ@mail.gmail.com>
 <CABdArM6Mfhk2+9TVR_D3cgfPWPfHDuZEg7MOc5KqULwt0OcQUg@mail.gmail.com>
 <CAA4eK1+d2vN80-Yvy_Hr=ATF3XL5db+_W-sXF=2Vxm+OFBO82w@mail.gmail.com>
 <CAA4eK1KxU4b53GUor41A55x+Bx-DdOaQ9g1DqURyRY2Cg-hhPQ@mail.gmail.com>
 <CABdArM6pmn5yFqiU33KTYBXYM=Vny2ULnJY_gqFbsMEdt+1dPA@mail.gmail.com>
 <CAHGQGwEsEjXbCthXb02=HScBW7C=BHmygv9SK1VGCcc-9bmTsw@mail.gmail.com>
 <CABdArM5rrhSmFvVL4C5LL0iea-R0HRtB=ZvD=ereoTDa1Tm=NA@mail.gmail.com>
 <CAHGQGwFaLPMWTHaPtxTpRb3_=d4o+SLu6+89BNEzALdEnvSWmQ@mail.gmail.com>
 <CABdArM7fPqd9GSXLLyDZfX_bZkAaoJAVDGKSQULfvEvVZZHgsg@mail.gmail.com>
 <CAJpy0uDaR4LKy2T=vLWuCnY8nQ=m7Zde_sr44aoYr7T0jodV2Q@mail.gmail.com>
 <CAHGQGwFC1qK3XiVi47VfJDNXE05HRA6AJmqrnAj55SK3kWTBkw@mail.gmail.com>
In-Reply-To: 
 <CAHGQGwFC1qK3XiVi47VfJDNXE05HRA6AJmqrnAj55SK3kWTBkw@mail.gmail.com>
From: Nisha Moond <nisha.moond412@gmail.com>
Date: Wed, 1 Apr 2026 10:33:43 +0530
Message-ID: 
 <CABdArM4XdB=vtQMVBBAowgf2PT7V8Dw56LfsYOAfyuxzcda6Ow@mail.gmail.com>
Subject: Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during
 promotion?
To: Fujii Masao <masao.fujii@gmail.com>
Cc: shveta malik <shveta.malik@gmail.com>,
 Amit Kapila <amit.kapila16@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CABdArM4XdB%3DvtQMVBBAowgf2PT7V8Dw56LfsYOAfyuxzcda6Ow%40mail.gmail.com>
Precedence: bulk

On Tue, Mar 31, 2026 at 9:03=E2=80=AFPM Fujii Masao <masao.fujii@gmail.com>=
 wrote:
>
> On Tue, Mar 31, 2026 at 7:42=E2=80=AFPM shveta malik <shveta.malik@gmail.=
com> wrote:
> > > > One idea would be to prevent the restart altogether. For example,
> > > > ProcessSlotSyncMessage() could set SlotSyncCtx->last_start_time to
> > > > a special value (like -1), and SlotSyncWorkerCanRestart() could ret=
urn
> > > > false (i.e., prevent postmater from starting up slotsync worker) wh=
en
> > > > it sees that. Alternatively, SlotSyncWorkerCanRestart() could simpl=
y
> > > > check SlotSyncCtx->stopSignaled.
> > > >
> > > > That said, as far as I remember correctly, postmaster is generally =
not
> > > > supposed to touch shared memory (per the comments in postmaster.c),
> > > > so I'm not sure this approach is acceptable. On the other hand,
> > > > postmaster and the slotsync worker already rely on SlotSyncCtx->las=
t_start_time,
> > > > so perhaps there's some precedent here.
> > > >
> > > IIUC, checking SlotSyncCtx->stopSignaled in SlotSyncWorkerCanRestart(=
)
> > > may not be ideal, as it requires a spinlock to avoid races with the
> > > startup process and it is disallowed to take lock in postmaster main
> > > loop. Whereas, SlotSyncCtx->last_start_time doesn=E2=80=99t need a lo=
ck since
> > > the postmaster accesses it only when the worker is not alive.
> > >
> >
> > I agree.
>
> Could you clarify what issue might arise from checking
> SlotSyncCtx->stopSignaled without holding a spinlock in
> SlotSyncWorkerCanRestart()? Is it actually problematic?
>

We might not see issues in practice since stopSignaled changes only
once (false -> true), so value corruption is unlikely.
But, without a lock or memory barrier, correct value-read is not
guaranteed, e.g., on weakly ordered systems (like ARM64) the
postmaster may still see a stale value. This means the worker could be
restarted again, and the same unwanted log may still appear.

> That said, since the postmaster should generally avoid
> touching shared memory, it doesn't seem like a good idea
> for it to check SlotSyncCtx->stopSignaled. So I'm fine with
> instead lowering the log level for the "worker will not start"
> message to DEBUG1.
>

Okay, thanks. I'll share the updated patch soon.

--
Thanks,
Nisha