On 22.01.25 05:00, Tom Lane wrote:
Peter Eisentraut <pe...@eisentraut.org> writes:
I have committed the fix for foreign key NO ACTION (patch 0002, this did
not require patch 0001).
That commit seems to be causing occasional buildfarm failures:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=indri&dt=2025-01-22%2001%3A29%3A35
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon&dt=2025-01-22%2001%3A17%3A14
Both of these look like
---
/Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/regress/expected/without_overlaps.out
2025-01-21 20:29:36
+++
/Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/regress/results/without_overlaps.out
2025-01-21 20:43:08
@@ -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
ie, an expected error did not get thrown.
I suspect the nested locking clauses in the new SQL query in the patch.
I don't see anything else in the patch that would possibly create this
kind unstable behavior.
Paul, what do you think?
I'll revert the patch soon unless we have a quick fix coming.
