Re: SQL:2011 application time
Paul A Jungwirth <pj@illuminatedcomputing.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rename gist stratnum support function
- 32edf732e8dc 18.0 landed
-
Remove support for temporal RESTRICT foreign keys
- b83e8a2ca2eb 18.0 landed
-
Cache NO ACTION foreign keys separately from RESTRICT foreign keys
- 9926f854d077 18.0 landed
-
Fix NO ACTION temporal foreign keys when the referenced endpoints change
- 1772d554b089 18.0 landed
-
Improve whitespace in without_overlaps test
- 888d4523f0c2 18.0 landed
-
Tests for logical replication with temporal keys
- 939b0908c87a 18.0 landed
-
Support for GiST in get_equal_strategy_number()
- 74edabce7a33 18.0 landed
-
Make the conditions in IsIndexUsableForReplicaIdentityFull() more explicit
- 13544e790ef8 18.0 landed
-
Replace get_equal_strategy_number_for_am() by get_equal_strategy_number()
- a2a475b011cf 18.0 landed
-
Improve internal logical replication error for missing equality strategy
- 321c287351f7 18.0 landed
-
Simplify IsIndexUsableForReplicaIdentityFull()
- 7727049e8f66 18.0 landed
-
Fix ALTER TABLE / REPLICA IDENTITY for temporal tables
- 79b575d3bc09 18.0 landed
-
doc: Update pg_constraint.conexclop docs for WITHOUT OVERLAPS
- f683ba0867da 18.0 landed
-
doc: Add PERIOD to ALTER TABLE reference docs
- d56af4c882e2 18.0 landed
-
doc: Add WITHOUT OVERLAPS to ALTER TABLE reference docs
- bf621059500b 18.0 landed
-
Add temporal FOREIGN KEY contraints
- 89f908a6d0ac 18.0 landed
- 34768ee36165 17.0 landed
-
Add temporal PRIMARY KEY and UNIQUE constraints
- fc0438b4e805 18.0 landed
- 46a0cd4cefb4 17.0 landed
-
Add stratnum GiST support function
- 7406ab623fee 18.0 landed
- 6db4598fcb82 17.0 landed
-
Avoid crashing when a JIT-inlined backend function throws an error.
- 5d6c64d29097 17.0 cited
-
Revert temporal primary keys and foreign keys
- 8aee330af55d 17.0 landed
-
Fix ON CONFLICT DO NOTHING/UPDATE for temporal indexes
- 144c2ce0cc75 17.0 landed
-
Add test for REPLICA IDENTITY with a temporal key
- 482e108cd38d 17.0 landed
-
Use half-open interval notation in without_overlaps tests
- 5577a71fb0cc 17.0 landed
-
Use daterange and YMD in without_overlaps tests instead of tsrange.
- a88c800deb6f 17.0 landed
-
Rename pg_constraint.conwithoutoverlaps to conperiod
- 030e10ff1a36 17.0 landed
-
Fix comment on gist_stratnum_btree
- 86232a49a437 17.0 landed
-
Add missing TAP test name
- 1ab763fc22ad 16.0 cited
-
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 cited
-
Rename functions to avoid future conflicts
- ee419607381d 15.0 landed
On 1/23/25 07:31, Peter Eisentraut wrote:
> On 22.01.25 05:00, Tom Lane wrote:
>> Peter Eisentraut <peter@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.
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.
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?
The strange thing is that the omitted error message is for a RESTRICT foreign key, and 1772d554b0
only changes behavior when is_no_action. That makes me think the bug is with the original temporal
FK commit. But that has been running on the build farm for a long time, so probably not.
Likewise, I don't see how it can be the nested locking, when that SQL isn't used for RESTRICT
constraints.
The infrequent failure made me suspect a memory error. It's hard to come up with explanations.
What about caching the FK's query plan? Could the RESTRICT test ever reuse the constraint oid from
the NO ACTION tests just above it? I'm pretty sure that's not supposed to happen, but if it used a
plan generated from the NO ACTION SQL, it would exhibit the behavior we're seeing. It also makes
sense why it only appeared after 1772d554b0.
I'll dig into that hypothesis and let you know if I figure anything out.
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com