On Sun, Jan 16, 2022 at 02:25:59PM -0600, Justin Pryzby wrote:
> 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.
I meant to say that I had not seen this issue anywhere but windows.
But now, by chance, I still had the 0001 patch in my tree, and hit the same
issue on linux:
https://cirrus-ci.com/task/4550618281934848
+++ /tmp/cirrus-ci-build/src/bin/pg_upgrade/tmp_check/regress/results/tuplesort.out 2022-01-17 16:06:35.759108172
+0000
EXPLAIN (COSTS OFF)
SELECT id, noabort_increasing, noabort_decreasing FROM abbrev_abort_uuids ORDER BY noabort_increasing LIMIT 5;
+ERROR: could not read block 0 in file "base/16387/t3_36794": read only 0 of 8192 bytes