Re: Failed to delete old ReorderBuffer spilled files

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Failed to delete old ReorderBuffer spilled files
Дата
Msg-id 20171122.131548.89810921.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Failed to delete old ReorderBuffer spilled files  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Failed to delete old ReorderBuffer spilled files
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] More stats about skipped vacuums
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: [HACKERS] Issues with logical replication