should ConstraintRelationId ins/upd cause relcache invals?

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Subject: should ConstraintRelationId ins/upd cause relcache invals?
Date: 2019-01-21 19:27:50
Message-ID: 201901211927.7mmhschxlejh@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


While working on bugfixes for FK problems in partitioned tables, I came
across some behavior that appears to stem from our inclusion of foreign
keys in relcache, without sufficient care for invalidating the relcache
entries when the foreign key set for the table changes. (Namely, a
partition retains its relcache entry with no FKs when an FK is added to
the parent table, leading a DELETE to skip running action triggers).

At I posted
a simplistic for the specific problem I found by calling
CacheInvalidateRelcache in the problem spot. But I'm wondering if the
correct fix isn't to have CacheInvalidateHeapTuple deal with FK
pg_constraint tuples instead, per the attached patch. Why does this not
lead to stale cache problems elsewhere?

FKs were added to relcache entries by commit 100340e2dcd0 ("Restore
foreign-key-aware estimation of join relation sizes"), so CCing Tom and

Álvaro Herrera PostgreSQL Expert,

Attachment Content-Type Size
relcache-fks.patch text/x-diff 1.9 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-01-21 19:33:00 Re: should ConstraintRelationId ins/upd cause relcache invals?
Previous Message Chapman Flack 2019-01-21 19:19:14 Re: House style for DocBook documentation?