| From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds) |
| Date: | 2020-09-23 14:39:10 |
| Message-ID: | cca5e8e2-ffcf-bd3a-f945-b391f74a7a7d@oss.nttdata.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020/09/23 12:47, Thomas Munro wrote:
> On Wed, Sep 23, 2020 at 2:27 PM David Rowley <dgrowleyml(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2020-09-23 14:49:09 | Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away |
| Previous Message | Ashutosh Bapat | 2020-09-23 13:58:53 | Re: Improper use about DatumGetInt32 |