Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds) - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)
Date
Msg-id cca5e8e2-ffcf-bd3a-f945-b391f74a7a7d@oss.nttdata.com
Whole thread Raw
In response to Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers

On 2020/09/23 12:47, Thomas Munro wrote:
> On Wed, Sep 23, 2020 at 2:27 PM David Rowley <dgrowleyml@gmail.com> wrote:
>> I've gone as far as running the recovery tests on the v3-0001 patch
>> using a Windows machine. They pass:
> 
> Thanks!  I pushed that one, because it was effectively a bug fix
> (WaitLatch() without a latch was supposed to work).

Great!


> 
> I'll wait longer for feedback on the main patch; perhaps someone has a
> better idea, or wants to take issue with the magic number 1024 (ie
> limit on how many records we'll replay before we notice the postmaster
> has exited), or my plan to harmonise those wait loops?  It has a CF
> entry for the next CF.

Does this patch work fine with warm-standby case using pg_standby?
IIUC the startup process doesn't call WaitLatch() in that case, so ISTM that,
with the patch, it cannot detect the postmaster death immediately.

Regards,

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



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Improper use about DatumGetInt32
Next
From: Fujii Masao
Date:
Subject: Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away