Re: Failed to delete old ReorderBuffer spilled files - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Failed to delete old ReorderBuffer spilled files
Date
Msg-id 20171122.131548.89810921.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Failed to delete old ReorderBuffer spilled files  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Failed to delete old ReorderBuffer spilled files  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
At Wed, 22 Nov 2017 12:57:34 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in
<CAB7nPqQP52cLEUZJv-1MoCiejNYQ4CGs=tzwhP2oEErvv7R3Bg@mail.gmail.com>
> On Wed, Nov 22, 2017 at 11:49 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> > On 20 November 2017 at 18:35, atorikoshi
> > <torikoshi_atsushi_z2@lab.ntt.co.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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] More stats about skipped vacuums
Next
From: Craig Ringer
Date:
Subject: Re: [HACKERS] Issues with logical replication