Horton

Thread

Commits

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

  1. Remove redundant SetLatch() calls in interrupt handling functions

  1. Avoid multiple SetLatch() calls in procsignal_sigusr1_handler()

    Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> — 2023-02-28T15:30:00Z

    Hi,

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.

I'm attaching a patch that avoids multiple SetLatch() calls.

Thoughts?

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

  2. Re: Avoid multiple SetLatch() calls in procsignal_sigusr1_handler()

    Kuntal Ghosh <kuntalghosh.2007@gmail.com> — 2023-03-01T09:44:36Z

    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

  3. Re: Avoid multiple SetLatch() calls in procsignal_sigusr1_handler()

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2023-03-09T12:24:32Z

    Hi,

On 2/28/23 4:30 PM, Bharath Rupireddy wrote:
> Hi,
> 
> Most of the multiplexed SIGUSR1 handlers are setting latch explicitly
> when the procsignal_sigusr1_handler() can do that for them at the end.

Right.

> These multiplexed handlers are currently being used as SIGUSR1
> handlers, not as independent handlers, so no problem if SetLatch() is
> removed from them. 

Agree, they are only used in procsignal_sigusr1_handler().

> A few others do it right by saying /* latch will be
> set by procsignal_sigusr1_handler */.

Yeap, so do HandleProcSignalBarrierInterrupt() and HandleLogMemoryContextInterrupt().

> Although, calling SetLatch() in
> quick succession does no harm (it just returns if the latch was
> previously set), it seems unnecessary.
> 

Agree.

> I'm attaching a patch that avoids multiple SetLatch() calls.
> 
> Thoughts?
> 

I agree with the idea behind the patch. The thing
that worry me a bit is that the changed functions are defined
as external and so may produce an impact outside of core pg and I'm
not sure that's worth it.

Otherwise the patch LGTM.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com