Re: STANDBY_LOCK_TIMEOUT may not interrupt ProcWaitForSignal()?

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: STANDBY_LOCK_TIMEOUT may not interrupt ProcWaitForSignal()?
Date: 2020-12-17 09:45:00
Message-ID: 826e8b24-feb6-5d75-6829-e58f437524b2@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020/12/17 11:04, Fujii Masao wrote:
> Hi,
>
> When the startup process needs to wait for recovery conflict on lock,
> STANDBY_LOCK_TIMEOUT is enabled to interrupt ProcWaitForSignal()
> if necessary. If this timeout happens, StandbyLockTimeoutHandler() is
> called and this function does nothing as follows.
>
>     /*
>      * StandbyLockTimeoutHandler() will be called if STANDBY_LOCK_TIMEOUT is exceeded.
>      * This doesn't need to do anything, simply waking up is enough.
>      */
>     void
>     StandbyLockTimeoutHandler(void)
>     {
>     }
>
> But if STANDBY_LOCK_TIMEOUT happens just before entering ProcWaitForSignal(),
> the timeout fails to interrupt that wait. Also a signal sent by this timeout
> doesn't interrupt poll() used in ProcWaitForSignal(), on all platforms.
>
> So I think that StandbyLockTimeoutHandler() should do SetLatch(MyLatch)
> so that the timeout can interrupt ProcWaitForSignal() even in those cases.
> Thought?

Patch attached.

Regards,

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

Attachment Content-Type Size
StandbyLockTimeoutHandler_SetLatch_v1.patch text/plain 589 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2020-12-17 11:05:33 Re: New Table Access Methods for Multi and Single Inserts
Previous Message Bharath Rupireddy 2020-12-17 09:36:59 Re: Fail Fast In CTAS/CMV If Relation Already Exists To Avoid Unnecessary Rewrite, Planning Costs