These are "my" animals (running at a local university). There's a couple
interesting details:
1) the animals run on the same machine (one with gcc, one with clang)
2) I did upgrade the OS and restarted the machine on 2024/02/26, i.e.
right before the failures started
These might be just coincidences, but maybe something got broken by the
upgrade ... OTOH it's weird it'd affect just HEAD and none of the other
branches, and on two difference compilers.
Just to be sure I removed the buildroot, in case there's something wrong
with ccache. It's a wild guess, but I don't have any other idea.
regards
On 3/2/24 22:39, Thomas Munro wrote:
> These two animals seem to have got mixed up about about the size of
> this relation in the same place:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=avocet&dt=2024-02-28%2017%3A34%3A30
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=trilobite&dt=2024-03-01%2006%3A47%3A53
>
> +++ /home/buildfarm/trilobite/buildroot/HEAD/pgsql.build/src/test/regress/results/constraints.out
> 2024-03-01 08:22:11.624897033 +0100
> @@ -573,42 +573,38 @@
> UNIQUE (i) DEFERRABLE INITIALLY DEFERRED;
> BEGIN;
> INSERT INTO unique_tbl VALUES (1, 'five');
> +ERROR: could not read blocks 0..0 in file "base/16384/21437": read
> only 0 of 8192 bytes
>
> That error message changed slightly in my smgrreadv() commit a couple
> of months ago (it would have been "block 0" and now it's "blocks 0..0"
> because now we can read more than one block at a time) but I don't
> immediately see how anything at that low level could be responsible
> for this.
>
>
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company