Re: PATCH: standby crashed when replay block which truncated instandby but failed to truncate in master node - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: PATCH: standby crashed when replay block which truncated instandby but failed to truncate in master node
Date
Msg-id 3f00f1ac-c490-5ed9-995a-f2e5cb3ef02e@oss.nttdata.com
Whole thread Raw
In response to Re: PATCH: standby crashed when replay block which truncated instandby but failed to truncate in master node  (Michael Paquier <michael@paquier.xyz>)
Responses Re: PATCH: standby crashed when replay block which truncated instandby but failed to truncate in master node  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers

On 2020/01/21 13:39, Michael Paquier wrote:
> On Tue, Jan 21, 2020 at 08:45:14AM +0530, Amit Kapila wrote:
>> The original email doesn't say so.  I might be missing something, but
>> can you explain what makes you think so.
> 
> Oops.  Incorrect thread, I was thinking about this one previously:
> https://www.postgresql.org/message-id/822113470.250068.1573246011818@connect.xfinity.com
> 
> Re-reading the root of the thread, I am still not sure what we could
> do, as that's rather tricky.  See here:
> https://www.postgresql.org/message-id/20190927061414.GF8485@paquier.xyz

The original proposal, i.e., holding the interrupts during
the truncation, is worth considering? It is not a perfect
solution but might improve the situation a bit.

Regards,

-- 
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Block level parallel vacuum
Next
From: Craig Ringer
Date:
Subject: Re: Physical replication slot advance is not persistent