Re: STANDBY_LOCK_TIMEOUT may not interrupt ProcWaitForSignal()?

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: STANDBY_LOCK_TIMEOUT may not interrupt ProcWaitForSignal()?
Дата
Msg-id 826e8b24-feb6-5d75-6829-e58f437524b2@oss.nttdata.com
обсуждение исходный текст
Ответ на STANDBY_LOCK_TIMEOUT may not interrupt ProcWaitForSignal()?  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: STANDBY_LOCK_TIMEOUT may not interrupt ProcWaitForSignal()?  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Fail Fast In CTAS/CMV If Relation Already Exists To Avoid Unnecessary Rewrite, Planning Costs
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: New Table Access Methods for Multi and Single Inserts