On 1/23/25 15:28, Tom Lane wrote:
Paul Jungwirth <p...@illuminatedcomputing.com> writes:
I can't find a regression.diffs in the second link. Is there one? I can't tell
if it's the same
failure as in the first link as not.
It is the same, but the diff is buried in some other file,
probably regress_log_027_stream_regress.
Ah yes, I found it. It's the same failure:
=== dumping
/home/bf/bf-build/mylodon/HEAD/pgsql.build/testrun/recovery/027_stream_regress/data/regression.diffs ===
diff -U3 /home/bf/bf-build/mylodon/HEAD/pgsql/src/test/regress/expected/without_overlaps.out
/home/bf/bf-build/mylodon/HEAD/pgsql.build/testrun/recovery/027_stream_regress/data/results/without_overlaps.out
--- /home/bf/bf-build/mylodon/HEAD/pgsql/src/test/regress/expected/without_overlaps.out 2025-01-21
13:46:02.766931451 +0000
+++
/home/bf/bf-build/mylodon/HEAD/pgsql.build/testrun/recovery/027_stream_regress/data/results/without_overlaps.out
2025-01-22 01:19:54.287558175 +0000
@@ -1792,8 +1792,6 @@
SET valid_at = CASE WHEN lower(valid_at) = '2018-01-01' THEN
daterange('2018-01-01', '2018-01-05')
WHEN lower(valid_at) = '2018-02-01' THEN daterange('2018-01-05',
'2018-03-01') END
WHERE id = '[6,7)';
-ERROR: update or delete on table "temporal_rng" violates RESTRICT setting of foreign key
constraint "temporal_fk_rng2rng_fk" on table "temporal_fk_rng2rng"
-DETAIL: Key (id, valid_at)=([6,7), [2018-01-01,2018-02-01)) is referenced from table
"temporal_fk_rng2rng".
-- a PK update that fails because both are referenced (even before commit):
BEGIN;
ALTER TABLE temporal_fk_rng2rng
=== EOF ===
I ran installcheck-parallel on my own machine continuously over night and
haven't been able to
reproduce this yet. How many cases have appeared on the build farm? More than
these two? And just to
confirm: they are only since committing 1772d554b0?
I've only noticed the two, but I did not mount an aggressive search.
It's possible that there were failures before 1772d554b0, since I
now see that the diff is in a test case that is older than that.
Okay, I'll keep in mind that it could be older.
The infrequent failure made me suspect a memory error. It's hard to come up
with explanations.
Same error on two different machines makes it hard to credit hardware
glitches, if that's what you mean. I could believe a bad pointer
accessing unpredictable memory, but perhaps valgrind would catch that.
Right, something like a bad pointer: the kind of memory error that *I* cause, not the celestial
bodies. But I don't think it's a great theory considering how clean, limited, and consistent the
test failure is.
Another thought was that the test here is UPDATing two rows at once, and somehow things happen in an
unusual order for these failures. But again for a RESTRICT check we're only querying the referencing
table. It really looks like the RESTRICT constraint is doing the 1772d554b0 NO ACTION check. . . .
Yours,
--
Paul ~{:-)
p...@illuminatedcomputing.com
