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
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 |