From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <tmunro(at)postgresql(dot)org> |
Subject: | Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843 |
Date: | 2020-11-04 23:07:37 |
Message-ID: | 18580b87-4b80-60c9-16f0-ab8d98395855@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/4/20 2:50 PM, Tomas Vondra wrote:
> On Wed, Nov 04, 2020 at 05:36:46PM +1300, Thomas Munro wrote:
>> On Wed, Nov 4, 2020 at 2:57 PM Tomas Vondra
>> <tomas(dot)vondra(at)2ndquadrant(dot)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(dot)vondra(at)2ndquadrant(dot)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?
>
> Seems to be working - without the patch it failed after ~1h, now it's
> running for more than 2h without a crash. I'll let it run for a few more
> hours (on both machines).
>
It's been running for hours on both machines, without any crashes etc.
While that's not a definitive proof the fix is correct, it certainly
behaves differently.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | James Coleman | 2020-11-04 23:53:32 | Re: Use of "long" in incremental sort code |
Previous Message | Melanie Plageman | 2020-11-04 22:33:58 | Re: Parallel Full Hash Join |