From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com> |
Subject: | Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds) |
Date: | 2020-09-17 10:47:31 |
Message-ID: | d7f1b944-dba3-e053-213b-83cbc63342d6@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 17/09/2020 13:31, Thomas Munro wrote:
> On Thu, Sep 17, 2020 at 10:19 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> If you put the counter in HandleStartupProcInterrupts(), it could be a
>> long wait if the startup process is e.g. waiting for WAL to arrive in
>> the loop in WaitForWALToBecomeAvailable(), or in recoveryPausesHere().
>> My original patch only reduced the frequency in the WAL redo loop, when
>> you're actively replaying records.
>
> Oh, I checked that WaitForWALToBecomeAvailable() already handled
> postmaster death via events rather than polling, with
> WL_EXIT_ON_PM_DEATH, but I hadn't clocked that recoveryPausesHere()
> uses pg_usleep() and polling. Hmm. Perhaps we should change that
> instead? The reason I did it that way is that I didn't want to make
> the new ProcSignalBarrierPending handler less reactive.
Hmm, so for speedy response to postmaster death, you're relying on the
loops to have other postmaster-death checks besides
HandleStartupProcInterrupts(), in the form of WL_EXIT_ON_PM_DEATH. That
seems a bit fragile, at the very least it needs a comment in
HandleStartupProcInterrupts() to call it out.
Note that there's one more loop in ShutdownWalRcv() that uses pg_usleep().
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2020-09-17 10:58:49 | Re: [HACKERS] [PATCH] Generic type subscripting |
Previous Message | Thomas Munro | 2020-09-17 10:31:04 | Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds) |