]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Try to handle torn reads of pg_control in frontend.
authorThomas Munro <tmunro@postgresql.org>
Mon, 16 Oct 2023 04:10:13 +0000 (17:10 +1300)
committerThomas Munro <tmunro@postgresql.org>
Mon, 16 Oct 2023 04:23:25 +0000 (17:23 +1300)
commitdc75748a918e3ba0fccf0aeb090068e1f172b3e9
tree5fe2658896097893a00485206c4aff7b79e29b4d
parenta56fe5cf07fea61f8d79570633298951697a3f72
Try to handle torn reads of pg_control in frontend.

Some of our src/bin tools read the control file without any kind of
interlocking against concurrent writes from the server.  At least ext4
and ntfs can expose partially modified contents when you do that.

For now, we'll try to tolerate this by retrying up to 10 times if the
checksum doesn't match, until we get two reads in a row with the same
bad checksum.  This is not guaranteed to reach the right conclusion, but
it seems very likely to.  Thanks to Tom Lane for this suggestion.

Various ideas for interlocking or atomicity were considered too
complicated, unportable or expensive given the lack of field reports,
but remain open for future reconsideration.

Back-patch as far as 12.  It doesn't seem like a good idea to put a
heuristic change for a very rare problem into the final release of 11.

Reviewed-by: Anton A. Melnikov <aamelnikov@inbox.ru>
Reviewed-by: David Steele <david@pgmasters.net>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de
src/common/controldata_utils.c