Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843
Дата
Msg-id CA+hUKGLw3T9hfdnMs=cqYn7F1ew=tX=ZBanw8=ueMATQNu-RyQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843
Список pgsql-hackers
On Wed, Nov 4, 2020 at 2:57 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> On Wed, Nov 04, 2020 at 02:49:24PM +1300, Thomas Munro wrote:
> >On Wed, Nov 4, 2020 at 2:32 PM Tomas Vondra
> ><tomas.vondra@2ndquadrant.com> wrote:
> >> After a while (~1h on my machine) the pg_multixact gets over 10GB, which
> >> triggers a more aggressive cleanup (per MultiXactMemberFreezeThreshold).
> >> My guess is that this discards some of the files, but checkpointer is
> >> not aware of that, or something like that. Not sure.
> >
> >Urgh.  Thanks.  Looks like perhaps the problem is that I have
> >RegisterSyncRequest(&tag, SYNC_FORGET_REQUEST, true) in one codepath
> >that unlinks files, but not another.  Looking.
>
> Maybe. I didn't have time to investigate this more deeply, and it takes
> quite a bit of time to reproduce. I can try again with extra logging or
> test some proposed fixes, if you give me a patch.

I think this should be fixed by doing all unlinking through a common
code path.  Does this pass your test?

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: "unix_socket_directories" should be GUC_LIST_INPUT?
Следующее
От: Peter Smith
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions