Re: PATCH: standby crashed when replay block which truncated instandby but failed to truncate in master node
От | Kyotaro Horiguchi |
---|---|
Тема | Re: PATCH: standby crashed when replay block which truncated instandby but failed to truncate in master node |
Дата | |
Msg-id | 20190924.144816.240830204.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: PATCH: standby crashed when replay block which truncated instandby but failed to truncate in master node (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: PATCH: standby crashed when replay block which truncated instandby but failed to truncate in master node
|
Список | pgsql-hackers |
At Tue, 24 Sep 2019 12:46:19 +0900 (Tokyo Standard Time), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in <20190924.124619.248088532.horikyota.ntt@gmail.com> > > clear about that. In short, as a matter of safety I'd like to think > > that what you are suggesting is rather acceptable (aka hold interrupts > > before the WAL record is written and release after the physical > > truncate), so as truncation avoids failures possible to avoid. > > > > Do others have thoughts to share on the matter? > > Agreed for the concept, but does the patch work as described? It > seems that query cancel doesn't fire during the holded-off > section since no CHECK_FOR_INTERRUPTS() there. Of course I found no *explicit* ones. But I found one ereport(DEBUG1 in register_dirty_segment. So it will work at least for the case where fsync request queue is full. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: