On Thu, Jan 13, 2022 at 09:52:55AM -0600, Justin Pryzby wrote:
> This is failing on windows CI when I use initdb --data-checksums, as attached.
>
> https://cirrus-ci.com/task/5612464120266752
> https://api.cirrus-ci.com/v1/artifact/task/5612464120266752/regress_diffs/src/test/regress/regression.diffs
>
> +++ c:/cirrus/src/test/regress/results/bitmapops.out 2022-01-13 00:47:46.704621200 +0000
> ..
> +ERROR: could not read block 0 in file "base/16384/30310": read only 0 of 8192 bytes
The failure isn't consistent, so I double checked my report. I have some more
details:
The problem occurs maybe only ~25% of the time.
The issue is in the 0001 patch.
data-checksums isn't necessary to hit the issue.
errlocation says: LOCATION: mdread, md.c:686 (the only place the error
exists)
With Andres' windows crash patch, I obtained a backtrace - attached.
https://cirrus-ci.com/task/5978171861368832
https://api.cirrus-ci.com/v1/artifact/task/5978171861368832/crashlog/crashlog-postgres.exe_0fa8_2022-01-16_02-54-35-291.txt
Maybe its a race condition or synchronization problem that nowhere else tends
to hit.
Separate from this issue, I wonder if it'd be useful to write a DEBUG log
showing when btree uses shared_buffers vs fsync. And a regression test which
first SETs client_min_messages=debug to capture the debug log to demonstrate
when/that new code path is being hit. I'm not sure if that would be good to
merge, but it may be useful for now.
--
Justin