| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pj(at)illuminatedcomputing(dot)com |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Temporal fkey bugs |
| Date: | 2026-09-11 18:51:52 |
| Message-ID: | sesqxzfcujkcnrwpir5xvhy7iamhsbjiqt6r2xqmb7hqkulte6@bbuc42qzanzs |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
While looking at FOR PORTION OF (see [1]), some AI tool noted that FPO can
lead to issues with temporal foreign keys. I don't think the issues were
really related to FPO, hence this new thread.
I don't think these are particularly hard to fix.
1) wrong lock level used with exclusion constraints
See exclusion-lock.spec.
The problem is that the constraint is an exclusion constraint, which relcache
doesn't include in the set of key-columns (as it's not unique). Which in turn
means that FOR KEY SHARE is used, which does not conflict with the UPDATE.
2) VALIDATE CONSTRAINT is broken
See validation.sql
QueueFKConstraintValidation() allocates a zeroed NewConstraint but omits
setting conwithperiod from conperiod. That leads to taking the wrong path in
validateForeignKeyConstraint().
FWIW, the issue it flagged with FPO was just that there can be temporary
spurious errors due to fkeys in some edge cases. But those are afaict also
present for non-FPO cases, and are arguably correct (the "problem" is what
snapshot is used to look for required rows, after waiting for the row lock on
a row deletion - a since then newly inserted row is not discovered).
Greetings,
Andres Freund
[1] https://postgr.es/m/vquveff5flfpsgsd55dkjqplhphziah7a7kggnemzfv5krrhet%40jxp5ubrpmxhy
| Attachment | Content-Type | Size |
|---|---|---|
| exclusion-lock.spec | text/plain | 1.7 KB |
| validation.sql | application/sql | 1.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-09-11 19:23:16 | Re: Temporal fkey bugs |
| Previous Message | Andres Freund | 2026-09-11 18:14:11 | Re: FOR PORTION OF code review |