Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)
От | Fujii Masao |
---|---|
Тема | Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds) |
Дата | |
Msg-id | cca5e8e2-ffcf-bd3a-f945-b391f74a7a7d@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds) (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)
|
Список | 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 по дате отправления: