From: | TAKATSUKA Haruka <harukat(at)sraoss(dot)co(dot)jp> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16172: failure of vacuum file truncation can cause permanent data corruption |
Date: | 2019-12-20 06:02:35 |
Message-ID: | 20191220150235.4b285807d448373a2dc773e1@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Horiguchi-san
Thanks for pointing out it.
I wasn't looking for past arguments enough.
You may mean this links are:
https://www.postgresql.org/message-id/flat/2348.1544474335%40sss.pgh.pa.us
https://www.postgresql.org/message-id/15667-8d3fca4eba25174f%40postgresql.org
regards,
TAKATSUKA Haruka
On Fri, 20 Dec 2019 14:22:22 +0900 (JST)
Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> Hello,
>
> At Fri, 20 Dec 2019 11:00:28 +0900, TAKATSUKA Haruka <harukat(at)sraoss(dot)co(dot)jp> wrote in
> >
> > I found moving DropRelFileNodeBuffers() from top to end in function
> > smgrtruncate() is a proper modification. It passed the regression test
> > and this reproduction test.
>
> I don't recall clealy but I think there was a thread similar to this
> issue. Assume that checkpoint was running concurrently, the
> checkpoint can revive the just truncated blocks inadvertently with
> bogus content.
>
> reagards.
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2019-12-20 10:41:32 | BUG #16173: PostgreSQL 9.6 service can not start after unexpected shutdown |
Previous Message | Kyotaro Horiguchi | 2019-12-20 05:22:22 | Re: BUG #16172: failure of vacuum file truncation can cause permanent data corruption |