Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Jan 18, 2021 at 3:25 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> If memory serves, the reason for the lock was that the CHECKPOINT
>> command used to run the checkpointing code directly in the calling
>> backend, so we needed it to keep more than one process from doing
>> that at once. AFAICS, it's no longer possible for more than one
>> process to try to run that code concurrently, so we shouldn't need
>> the lock anymore.
> Interesting. I think that must have been a *very* long time ago.
Yeah. Digging further, it looks like I oversimplified things above:
we once launched special background-worker-like processes for checkpoints,
and there could be more than one at a time. That seems to have changed
here:
Author: Tom Lane <t...@sss.pgh.pa.us>
Branch: master Release: REL8_0_BR [076a055ac] 2004-05-29 22:48:23 +0000
Separate out bgwriter code into a logically separate module, rather
than being random pieces of other files. Give bgwriter responsibility
for all checkpoint activity (other than a post-recovery checkpoint);
so this child process absorbs the functionality of the former transient
checkpoint and shutdown subprocesses.
At the time I thought the CheckpointLock had become totally pro forma,
but there are later references to having to prevent a checkpoint from
running concurrently with a restartpoint, which was originally done
within the startup/WAL-replay process. It looks like that changed here:
Author: Heikki Linnakangas <heikki.linnakan...@iki.fi>
Branch: master Release: REL8_4_BR [7e48b77b1] 2009-06-25 21:36:00 +0000
Fix some serious bugs in archive recovery, now that bgwriter is active
during it:
When bgwriter is active, the startup process can't perform mdsync()
correctly
because it won't see the fsync requests accumulated in bgwriter's private
pendingOpsTable. Therefore make bgwriter responsible for the end-of-recovery
checkpoint as well, when it's active.
(The modern checkpointer process wasn't split out of bgwriter until
806a2aee3 of 2011-11-01.)
regards, tom lane
