aboutsummaryrefslogtreecommitdiff
path: root/src/backend/jit/llvm/llvmjit_wrap.cpp
diff options
context:
space:
mode:
authorThomas Munro <tmunro@postgresql.org>2023-10-16 17:10:13 +1300
committerThomas Munro <tmunro@postgresql.org>2023-10-16 17:25:43 +1300
commit43c979086825e5df1816307fea9b41378cdc31bd (patch)
treed19f68b5a4a37512a35534fe9b3b521bf6020de7 /src/backend/jit/llvm/llvmjit_wrap.cpp
parent637e86ecc5e4fcc5447b67d83337bc8752a40a52 (diff)
downloadpostgresql-43c979086825e5df1816307fea9b41378cdc31bd.tar.gz
postgresql-43c979086825e5df1816307fea9b41378cdc31bd.zip
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
Diffstat (limited to 'src/backend/jit/llvm/llvmjit_wrap.cpp')
0 files changed, 0 insertions, 0 deletions