public inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Andres Freund <[email protected]>
To: Melanie Plageman <[email protected]>
To: Noah Misch <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: [email protected]
Cc: Thomas Munro <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Michael Paquier <[email protected]>
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
Date: Sat, 7 Feb 2026 14:38:53 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <5ubipyssiju5twkb7zgqwdr7q2vhpkpmuelxfpanetlk6ofnop@hvxb4g2amb2d>
References: <q3ybyaiownp4ivt6xfy55s5llvtq6vqsd4zbt5kn6hacxdcpp4@2ngd4h4bev5d>
<dsbacri4xldlobl3jbqqlksefsyrwj7lzljbohxsbqjus3z4o7@otb6rge4w7az>
<[email protected]>
<5dwlfu2jyzkyf3nrlzxxblxctb6xio5es73ptgsahjnmfu5miu@772rc764hfhi>
<ossv2eistssmubfsir6xjll76tynvxv5lup4zkrfzjkud7fycw@rf5vii6l6cha>
<4csodkvvfbfloxxjlkgsnl2lgfv2mtzdl7phqzd4jxjadxm4o5@usw7feyb5bzf>
<CALdSSPgyc7VuMLUZ8J7v2G-PebBa_vEi+mp-cLkcOwNycB56Hw@mail.gmail.com>
<kjdgvws34gpnz4y6xu5aaeul5mspgy3ahvyiw4lndb3ecsacdb@b2ccyowotpqh>
<jtg5cu4n6h5lib3kzx66ju4yhh6kmviaud7oq6dtut6c4q4rdi@xwsfoagt3c2b>
<k5j77f3q6ztihnjnx2nqxzyor6fbj2qxcbhzuxhkh2yy63jyfg@p72phigar3n4>
<5ubipyssiju5twkb7zgqwdr7q2vhpkpmuelxfpanetlk6ofnop@hvxb4g2amb2d>
On 03/02/2026 00:33, Andres Freund wrote:
> - Now that we use the normal order of WAL logging, we don't need to delay
> checkpoint starts anymore.
>
> I think the explanation for why that is ok is correct [1], but it needs to
> be looked at by somebody with experience around this. Maybe Heikki?
So that's patch 0004 "bufmgr: Switch to standard order in
MarkBufferDirtyHint()". Yes, looks correct to me.
> /*
> * Update RedoRecPtr so that we can make the right decision. It's possible
> * that a new checkpoint will start just after GetRedoRecPtr(), but that
> * is ok, as the buffer is already dirty, ensuring that any BufferSync()
> * started after the buffer was marked dirty cannot complete without
> * flushing this buffer. If a checkpoint started between marking the
> * buffer dirty and this check, we will emit an unnecessary WAL record (as
> * the buffer will be written out as part of the checkpoint), but the
> * window for that is small.
> */
> RedoRecPtr = GetRedoRecPtr();
That "small window" is actually pretty big if you think of it a little
more loosely. Our rule is that we write the full page image if a
checkpoint has started since the page LSN, but that's very conservative
already. It would be sufficient to write the full page image only if the
checkpoint has already flushed the page. This small window is just a
special case of that conservatism.
I've been thinking of trying track that more accurately for a long time,
because it would smoothen the WAL spike when a checkpoint begins.
That gets off-topic, but my point is that it feels a little silly to
mention that small window when there's the other giant panoramic window
next to it.
- Heikki
view thread (35+ messages) latest in thread
reply
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: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox