Re: Failures in constraints regression test, "read only 0 of 8192 bytes"

On 3/8/24 13:21, Tomas Vondra wrote:
> On 3/8/24 09:33, Thomas Munro wrote:
>> Happened again.  I see this is OpenSUSE.  Does that mean the file
>> system is Btrfs?
> 
> 
> It is, but I don't think that matters - I've been able to reproduce this
> locally on my laptop using ext4 filesystem. I'd bet the important piece
> here is -DCLOBBER_CACHE_ALWAYS (and it seems avocet/trilobite are the
> only animals running with this).
> 
> Also, if this really is a filesystem (or environment) issue, it seems
> very strange it'd only affect HEAD and not the other branches. So it
> seems quite likely this is actually triggered by a commit.
> 
> Looking at the commits from the good/bad runs, I see this:
> 
> avocet: good=4c2369a bad=f5a465f
> trilobite: good=d13ff82 bad=def0ce3
> 
> That means the commit would have to be somewhere here:
> 
> f5a465f1a07 Promote assertion about !ReindexIsProcessingIndex to ...
> 57b28c08305 Doc: fix minor typos in two ECPG function descriptions.
> 28e858c0f95 Improve documentation and GUC description for ...
> a661bf7b0f5 Remove flaky isolation tests for timeouts
> 874d817baa1 Multiple revisions to the GROUP BY reordering tests
> 466979ef031 Replace lateral references to removed rels in subqueries
> a6b2a51e16d Avoid dangling-pointer problem with partitionwise ...
> d360e3cc60e Fix compiler warning on typedef redeclaration
> 8af25652489 Introduce a new smgr bulk loading facility.
> e612384fc78 Fix mistake in SQL features list
> d13ff82319c Fix BF failure in commit 93db6cbda0.
> 
> My guess would be 8af25652489, as it's the only storage-related commit.
> 
> I'm currently running tests to verify this.
> 

Yup, the breakage starts with this commit. I haven't looked into the
root cause, or whether the commit maybe just made some pre-existing
issue easier to hit. Also, I haven't followed the discussion on the
pgsql-bugs thread [1], maybe there are some interesting findings.

[1]
https://www.postgresql.org/message-id/flat/1878547.tdWV9SEqCh%40aivenlaptop


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company