Re: Failures in constraints regression test, "read only 0 of 8192 bytes"
От | Tomas Vondra |
---|---|
Тема | Re: Failures in constraints regression test, "read only 0 of 8192 bytes" |
Дата | |
Msg-id | e4f94648-4236-4358-b64c-6a935e33658d@enterprisedb.com обсуждение исходный текст |
Ответ на | Failures in constraints regression test, "read only 0 of 8192 bytes" (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Failures in constraints regression test, "read only 0 of 8192 bytes"
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: