Re: should ConstraintRelationId ins/upd cause relcache invals?

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas.vondra@2ndquadrant.com>
Date: 2019-01-21T22:42:02Z
Lists: pgsql-hackers
Hi,

On 2019-01-21 19:40:17 -0300, Alvaro Herrera wrote:
> On 2019-Jan-21, Tom Lane wrote:
> 
> > Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> 
> > > 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.
> 
> Thanks, pushed.

Given https://www.postgresql.org/message-id/20190121193300.gknn7p4pmmjg7nqf%40alap3.anarazel.de
and the concerns voiced in the thread quoted therein, I'm a bit
surprised that you just went ahead with this, and backpatched it to boot.

Greetings,

Andres Freund


Commits

  1. Flush relcache entries when their FKs are meddled with

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