Re: PATCH: standby crashed when replay block which truncated in standby but failed to truncate in master node

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: michael(at)paquier(dot)xyz
Cc: tomas(dot)vondra(at)2ndquadrant(dot)com, thunder1(at)126(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: PATCH: standby crashed when replay block which truncated in standby but failed to truncate in master node
Date: 2019-09-24 05:48:16
Message-ID: 20190924.144816.240830204.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 24 Sep 2019 12:46:19 +0900 (Tokyo Standard Time), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in <20190924(dot)124619(dot)248088532(dot)horikyota(dot)ntt(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Surafel Temesgen 2019-09-24 06:25:01 Re: Option to dump foreign data in pg_dump
Previous Message David Fetter 2019-09-24 05:26:21 Re: Efficient output for integer types