From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | michael(dot)paquier(at)gmail(dot)com |
Cc: | craig(at)2ndquadrant(dot)com, torikoshi_atsushi_z2(at)lab(dot)ntt(dot)co(dot)jp, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Failed to delete old ReorderBuffer spilled files |
Date: | 2017-11-22 04:15:48 |
Message-ID: | 20171122.131548.89810921.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 22 Nov 2017 12:57:34 +0900, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote in <CAB7nPqQP52cLEUZJv-1MoCiejNYQ4CGs=tzwhP2oEErvv7R3Bg(at)mail(dot)gmail(dot)com>
> On Wed, Nov 22, 2017 at 11:49 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> > On 20 November 2017 at 18:35, atorikoshi
> > <torikoshi_atsushi_z2(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> >> I put many queries into one transaction and made ReorderBuffer spill
> >> data to disk, and sent SIGKILL to postgres before the end of the
> >> transaction.
> >>
> >> After starting up postgres again, I observed the files spilled to
> >> data wasn't deleted.
> >
> > Since this can only happen on crash exits, and the reorderbuffer data is
> > useless after a decoding backend exits, why don't we just recursively delete
> > the tree contents on Pg startup?
>
> +1. You would just need an extra step after say
> DeleteAllExportedSnapshotFiles() in startup.c. Looks saner to me do so
> so as well.
The old files are being removed at startup by
StartupReorderBuffer.
At the time of assertion failure, the files are not of the
previous run, but they are created after reconnection from the
subscriber.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2017-11-22 04:19:54 | Re: [HACKERS] Issues with logical replication |
Previous Message | Michael Paquier | 2017-11-22 04:12:33 | Re: [HACKERS] More stats about skipped vacuums |