| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Subject: | Re: should ConstraintRelationId ins/upd cause relcache invals? |
| Date: | 2019-01-21 22:42:02 |
| Message-ID: | 20190121224202.nlu7x53kgfesqyml@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2019-01-21 23:03:10 | RelationGetIndexAttrBitmap() small deviation between comment and code |
| Previous Message | Alvaro Herrera | 2019-01-21 22:40:17 | Re: should ConstraintRelationId ins/upd cause relcache invals? |