Improve handling of concurrent checksum requests
When pg_{enable|disable}_data_checksums is called while checksums are
being enabled or disabled, the already running launcher is detected
and the new desired state is recorded. Processing will then pick up
the new state and change its operation to fulfill the new request.
If the same state is requested but with different cost values, the
new cost values will take effect on the next relation processed.
The previous coding had a complex logic of starting a new launcher
for this, which is now avoided with the shared mem structure instead
used to signal current processing.
This makes the logic more robust, and fixes a bug where the launcher
would erroneously revert back to the "off" state.
Access to the shared memory is also protected with LWLocks in all
cases. Since the shmem structure is used for signalling between
the worker and the launcher, and there can be only one of each,
there were no concurrency issues detected but it's better to stick
to proper locking protocol should this ever be updated to handle
multiple workers.
Author: Daniel Gustafsson <[email protected]>
Reviewed-by: Tomas Vondra <[email protected]>
Reviewed-by: SATYANARAYANA NARLAPURAM <[email protected]>
Reviewed-by: Ayush Tiwari <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/bf25e5571b325875e0e48bac2e59a820918f2d6a
Modified Files
--------------
src/backend/access/transam/xlog.c | 33 ++++++++-
src/backend/postmaster/datachecksum_state.c | 100 ++++++++++++++++++++++------
src/include/access/xlog.h | 2 +
3 files changed, 112 insertions(+), 23 deletions(-)
