Re: Avoid multiple SetLatch() calls in procsignal_sigusr1_handler() - Mailing list pgsql-hackers

From Kuntal Ghosh
Subject Re: Avoid multiple SetLatch() calls in procsignal_sigusr1_handler()
Date
Msg-id CAGz5QCLd8wm_KxZW=W+=roHnv+yS8pvw2qLP=G=FxDH53aee_g@mail.gmail.com
Whole thread Raw
In response to Avoid multiple SetLatch() calls in procsignal_sigusr1_handler()  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
On Tue, Feb 28, 2023 at 9:01 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Most of the multiplexed SIGUSR1 handlers are setting latch explicitly
> when the procsignal_sigusr1_handler() can do that for them at the end.
> These multiplexed handlers are currently being used as SIGUSR1
> handlers, not as independent handlers, so no problem if SetLatch() is
> removed from them. A few others do it right by saying /* latch will be
> set by procsignal_sigusr1_handler */. Although, calling SetLatch() in
> quick succession does no harm (it just returns if the latch was
> previously set), it seems unnecessary.
>
+1



--
Thanks & Regards,
Kuntal Ghosh



pgsql-hackers by date:

Previous
From: Jim Jones
Date:
Subject: Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)
Next
From: Jehan-Guillaume de Rorthais
Date:
Subject: Re: Memory leak from ExecutorState context?