| 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-25 06:55:46 |
| Message-ID: | 20190925.155546.01376674.horikyota.ntt@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
At Wed, 25 Sep 2019 12:24:03 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in <20190925032403(dot)GF1815(at)paquier(dot)xyz>
> On Tue, Sep 24, 2019 at 02:48:16PM +0900, Kyotaro Horiguchi wrote:
> > 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.
>
> Exactly. I have not checked the patch in details, but I think that
> we should not rely on the assumption that no code paths in this area do
> not check after CHECK_FOR_INTERRUPTS() as smgrtruncate() does much
> more than just the physical segment truncation.
Agreed to the point. Just I doubted that it really fixes the
author's problem. And confirmed that it can be.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-09-25 07:15:43 | Re: [PATCH] Sort policies and triggers by table name in pg_dump. |
| Previous Message | Michael Paquier | 2019-09-25 06:55:14 | Re: PostgreSQL12 and older versions of OpenSSL |