Remove CheckpointLock.
authorRobert Haas
Mon, 25 Jan 2021 17:34:00 +0000 (12:34 -0500)
committerRobert Haas
Mon, 25 Jan 2021 17:34:38 +0000 (12:34 -0500)
commitd18e75664a2fda2e4d5cc433d68e37fc0e9499f2
treee33cbb6c12b17bdcd7751b467b028917e45fa0db
parent951862eda57e5dc8f78c97b3c30fe2032a5562b8
Remove CheckpointLock.

Up until now, we've held this lock when performing a checkpoint or
restartpoint, but commit 076a055acf3c55314de267c62b03191586d79cf6 back
in 2004 and commit 7e48b77b1cebb9a43f9fdd6b17128a0ba36132f9 from 2009,
taken together, have removed all need for this. In the present code,
there's only ever one process entitled to attempt a checkpoint: either
the checkpointer, during normal operation, or the postmaster, during
single-user operation. So, we don't need the lock.

One possible concern in making this change is that it means that
a substantial amount of code where HOLD_INTERRUPTS() was previously
in effect due to the preceding LWLockAcquire() will now be
running without that. This could mean that ProcessInterrupts()
gets called in places from which it didn't before. However, this
seems unlikely to do very much, because the checkpointer doesn't
have any signal mapped to die(), so it's not clear how,
for example, ProcDiePending = true could happen in the first
place. Similarly with ClientConnectionLost and recovery conflicts.

Also, if there are any such problems, we might want to fix them
rather than reverting this, since running lots of code with
interrupt handling suspended is generally bad.

Patch by me, per an inquiry by Amul Sul. Review by Tom Lane
and Michael Paquier.

Discussion: http://postgr.es/m/CAAJ_b97XnBBfYeSREDJorFsyoD1sHgqnNuCi=02mNQBUMnA=FA@mail.gmail.com
doc/src/sgml/monitoring.sgml
src/backend/access/heap/rewriteheap.c
src/backend/access/transam/xlog.c
src/backend/replication/logical/origin.c
src/backend/storage/lmgr/lwlocknames.txt