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  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: Efficient output for integer types
Следующее
От: Surafel Temesgen
Дата:
Сообщение: Re: Option to dump foreign data in pg_dump