Re: should ConstraintRelationId ins/upd cause relcache invals? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: should ConstraintRelationId ins/upd cause relcache invals?
Date
Msg-id 20190121224202.nlu7x53kgfesqyml@alap3.anarazel.de
Whole thread Raw
In response to Re: should ConstraintRelationId ins/upd cause relcache invals?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: should ConstraintRelationId ins/upd cause relcache invals?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: should ConstraintRelationId ins/upd cause relcache invals?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: should ConstraintRelationId ins/upd cause relcache invals?
Next
From: David Rowley
Date:
Subject: RelationGetIndexAttrBitmap() small deviation between comment and code