Horton

Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

Fujii Masao <masao.fujii@oss.nttdata.com>

View thread View on postgr.es
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-12-15T14:10:28Z
Lists: pgsql-hackers 

On 2020/11/04 18:06, Fujii Masao wrote:
> 
> 
> On 2020/10/29 15:21, Fujii Masao wrote:
>>
>>
>> On 2020/10/07 11:30, Bharath Rupireddy wrote:
>>> On Tue, Oct 6, 2020 at 11:41 AM Bharath Rupireddy
>>> <bharath.rupireddyforpostgres@gmail.com> wrote:
>>>>
>>>> On Tue, Oct 6, 2020 at 11:20 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>>>>
>>>>> +1 Or it's also ok to make each patch separately.
>>>>> Anyway, thanks!
>>>>>
>>>>
>>>> Thanks. +1 to have separate patches. I will post two separate patches
>>>> for autoprewarm and WalRcvShutdownHandler for further review. The
>>>> other two patches can be for startup.c and syslogger.c.
>>>>
>>>
>>> I'm attaching all the 4 patches here together.
>>>
>>> 1. v1-use-standard-SIGHUP-and-SIGTERM-handlers-in-autoprewarm-process.patch
>>> --  This is the patch initially sent in this mail by me, I just
>>> renamed it.
>>> 2. v1-use-MyLatch-and-standard-SIGHUP-handler-in-startup-process.patch
>>> -- This is the patch proposed by Fuji Masao, I just renamed it.
>>> 3. v1-use-standard-SIGHUP-hanlder-in-syslogger-process.patch
>>> 4. v1-use-standard-SIGTERM-handler-in-walreceiver-process.patch
>>>
>>> Please consider these patches for further review.
>>
>> Thanks for the patches! They look good to me. So barring any objections,
>> I will commit them one by one.
> 
> I pushed the following two patches.
> 
> - v1-use-standard-SIGHUP-hanlder-in-syslogger-process.patch
> - v1-use-MyLatch-and-standard-SIGHUP-handler-in-startup-process.patch

As I told in other thread [1], I'm thinking to revert this patch
because this change could have bad side-effect on the startup
process waiting for recovery conflict.

Before applying the patch, the latch that the startup process
used to wait for recovery conflict was different from the latch
that SIGHUP signal handler or walreceiver process, etc set to
wake the startup process up. So SIGHUP or walreceiver didn't
wake the startup process waiting for recovery conflict up unnecessary.

But the patch got rid of the dedicated latch for signaling
the startup process. This change forced us to use the same latch
to make the startup process wait or wake up. Which caused SIGHUP
signal handler or walreceiver proces to wake the startup process
waiting on the latch for recovery conflict up unnecessarily frequently.

While waiting for recovery conflict on buffer pin, deadlock needs
to be checked at least every deadlock_timeout. But that frequent
wakeups could prevent the deadlock timer from being triggered and
could delay that deadlock checks.

Therefore, I'm thinking to revert the commit ac22929a26 and 113d3591b8.

[1]
https://www.postgresql.org/message-id/a802f1c0-58d9-bd3f-bc3e-bdad54726855@oss.nttdata.com

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

Commits

  1. Revert "Get rid of the dedicated latch for signaling the startup process".

  2. Improve log message about termination of background workers.

  3. Use standard SIGTERM signal handler die() in test_shm_mq worker.

  4. Use standard SIGHUP and SIGTERM signal handlers in worker_spi.

  5. Use standard SIGHUP and SIGTERM handlers in walreceiver.

  6. pg_prewarm: make autoprewarm leader use standard SIGHUP and SIGTERM handlers.

  7. Get rid of the dedicated latch for signaling the startup process.

  8. Use standard SIGHUP handler in syslogger.

  9. Use PostgresSigHupHandler in more places.

  10. Fix race condition with unprotected use of a latch pointer variable.

  11. Remove remnants of ImmediateInterruptOK handling.

  12. Introduce Streaming Replication.