database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-25 13:17:41 +03:00
Code Activity

Comment on need to MarkBufferDirty() if omitting DELAY_CHKPT_START.

Browse Source 
Blocking checkpoint phase 2 requires MarkBufferDirty() and
BUFFER_LOCK_EXCLUSIVE; neither suffices by itself.  transam/README documents
this, citing SyncOneBuffer().  Update the DELAY_CHKPT_START documentation to
say this.  Expand the heap_inplace_update_and_unlock() comment that cites
XLogSaveBufferForHint() as precedent, since heap_inplace_update_and_unlock()
could have opted not to use DELAY_CHKPT_START.

Commit 8e7e672cda added DELAY_CHKPT_START to
heap_inplace_update_and_unlock().  Since commit
bc6bad8857 reverted it in non-master branches,
no back-patch.

Discussion: https://postgr.es/m/20250406180054.26.nmisch@google.com
This commit is contained in:
Noah Misch
2025-04-20 12:00:17 -07:00
parent 714bd9e3a7
commit 8180136652
2 changed files with 15 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
src/include/storage/proc.h
View File

@@ -110,10 +110,10 @@ extern PGDLLIMPORT int FastPathLockGroupsPerBackend;
* is inserted prior to the new redo point, the corresponding data changes will
* also be flushed to disk before the checkpoint can complete. (In the
* extremely common case where the data being modified is in shared buffers
* and we acquire an exclusive content lock on the relevant buffers before
* writing WAL, this mechanism is not needed, because phase 2 will block
* until we release the content lock and then flush the modified data to
* disk.)
* and we acquire an exclusive content lock and MarkBufferDirty() on the
* relevant buffers before writing WAL, this mechanism is not needed, because
* phase 2 will block until we release the content lock and then flush the
* modified data to disk. See transam/README and SyncOneBuffer().)
*
* Setting DELAY_CHKPT_COMPLETE prevents the system from moving from phase 2
* to phase 3. This is useful if we are performing a WAL-logged operation that