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

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Thunder <thunder1(at)126(dot)com>, PostgreSQL Hackers <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: 2020-01-21 06:41:54
Message-ID: 3f00f1ac-c490-5ed9-995a-f2e5cb3ef02e@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2020-01-21 06:57:33 Re: Physical replication slot advance is not persistent
Previous Message Masahiko Sawada 2020-01-21 06:40:48 Re: [HACKERS] Block level parallel vacuum