Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843 - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843
Date
Msg-id CA+hUKGLw3T9hfdnMs=cqYn7F1ew=tX=ZBanw8=ueMATQNu-RyQ@mail.gmail.com
Whole thread Raw
In response to Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List 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?

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: "unix_socket_directories" should be GUC_LIST_INPUT?
Next
From: Peter Smith
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions