public inbox for [email protected]
help / color / mirror / Atom feedFrom: Paul Jungwirth <[email protected]>
To: Tom Lane <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: jian he <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: vignesh C <[email protected]>
Subject: Re: SQL:2011 application time
Date: Thu, 23 Jan 2025 15:54:15 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<5f0c25de-2c13-4fb5-a4df-a1e03c43cd14@illuminatedcomputin! g.com>
<[email protected]>
<[email protected]>
<[email protected]>
<bca3e7e6-ac1f-476d-9725-d6aec9100ed0@illumin! atedcomputing.com>
<[email protected]>
On 1/23/25 15:28, Tom Lane wrote:
> Paul Jungwirth <[email protected]> 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 ~{:-)
[email protected]
view thread (23+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: SQL:2011 application time
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox