Re: should ConstraintRelationId ins/upd cause relcache invals?

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas.vondra@2ndquadrant.com>
Date: 2019-01-21T20:08:17Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> 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).

Ooops.

> At https://postgr.es/m/201901182216.nr5clsxrn624@alvherre.pgsql 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.

+1, this is safer than expecting retail relcache inval calls to be
added in all the right places.

			regards, tom lane


Commits

  1. Flush relcache entries when their FKs are meddled with

  2. Restore foreign-key-aware estimation of join relation sizes.