From: Nathan Bossart <nathandbossart@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: USE_BARRIER_SMGRRELEASE on Linux?
Date: Wed, 16 Feb 2022 13:00:53 -0800
Message-ID: <20220216210053.GA3031150@nathanxps13> (raw)
In-Reply-To: <20220216192731.txn3vnlooa2bhdsm@alap3.anarazel.de>
References: <20220215235845.GA2665318@nathanxps13>
<CA+hUKGJxb5ug=sBL=S8WMsFg4mojccy8p1VWqXYEz4MSre_vGA@mail.gmail.com>
<CA+hUKG+Ye6kBWkm9kjMhvAvO0gyrEy=q3rm05XSmZ2ah6auQNw@mail.gmail.com>
<20220216045911.GA2791824@nathanxps13>
<20220216050645.7u3nguccykpqaw7p@alap3.anarazel.de>
<20220216061404.GA2813338@nathanxps13>
<20220216065732.GA2932808@nathanxps13>
<20220216164442.GA2935315@nathanxps13>
<20220216173721.GA3007497@nathanxps13>
<20220216192731.txn3vnlooa2bhdsm@alap3.anarazel.de>
On Wed, Feb 16, 2022 at 11:27:31AM -0800, Andres Freund wrote:
> Did you check whether this is a problem recently introduced or long-lived?
I've reproduced it back to v9.3. I'm assuming it's much older than that.
> Does USE_BARRIER_SMGRRELEASE actually prevent this problem? Or was it just
> that it influences the timing in a way that makes it less likely?
I think it just influences the timing. I believe the WAL pre-allocation
stuff triggers the issue because it adds a step between
AbsorbSyncRequests() and incrementing the started counter.
> ISTM that the problem is partially caused by having multiple "checkpoint"
> counters that are used in different ways, but then only waiting for one of
> them. I wonder whether a better approach could be to either unify the
> different counters, or to request / wait for the sync counter specifically?
>
> Historically the sync stuff was something in md.c that the global system
> didn't really know anything about, but now it's a "proper" subsystem, so we
> can change the separation of concerns a bit more.
If the counters were unified, I think we might still need to do an extra
aborb after incrementing it, and we'd need to make sure that all of those
requests were tagged with the previous counter value so that they are
processed in the current checkpoint. If callers requested with a specific
counter value, they might need to lock the counter (ckpt_lck) when making
requests. Maybe that is okay.
>> Here's a patch that adds a call to AbsorbSyncRequests() in
>> CheckpointerMain() instead of SyncPreCheckpoint().
>
> That doesn't strike me as great architecturally. E.g. in theory the same
> problem could exist in single user mode. I think it doesn't today, because
> RegisterSyncRequest() will effectively "absorb" it immediately, but that kind
> of feels like an implementation detail?
Yeah, maybe that is a reason to add an absorb somewhere within
CreateCheckPoint() instead, like v1 [0] does. Then the extra absorb would
be sufficient for single-user mode if the requests were not absorbed
immediately.
[0] https://www.postgresql.org/message-id/attachment/130994/v1-0001-call-AbsorbSyncRequests-before-advan...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, andres@anarazel.de, thomas.munro@gmail.com
Subject: Re: USE_BARRIER_SMGRRELEASE on Linux?
In-Reply-To: <20220216210053.GA3031150@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox