Re: should ConstraintRelationId ins/upd cause relcache invals?

Hi,

On 2019-01-21 20:25:46 -0300, Alvaro Herrera wrote:
> Hello
>
> On 2019-Jan-21, Andres Freund wrote:
>
> > 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.
>
> Sigh.

> I don't understand why the arguments about a different patch apply to
> this one. The invalidation I added is for pg_constraint, not pg_index.

> Tom argues that pg_index can be updated for reasons other than
> creation/deletion of the index, and that the relcache entry should not
> be invalidated in those cases.

So can pg_constraint in some cases, that's not an argument (we'll now
e.g. re-compute the table's relcache entry more times than before after
e.g. renaming an index - arguably we could fix that by fixing the
relcache mechanism to not redundantly re-build).

> OTOH I lean towards your side of the argument in the other thread and I
> don't quite understand why you gave up on it. Tom didn't respond to
> your last argumentat, and neither did you indicate that you were
> convinced by Tom's argumentation.

I wasn't. My concern isn't that we shouldn't do this, but that we ought
to go about this a bit more systematically than just doing this for an
individual object type, depending on the mood of the day. Cache
invalidation is hard enough to understand already, the more inconsistent
we make it harder it is to get it right going forward.

> My conclusion is that you disagreed but decided not to push the issue
> any further, to get the thing done. What I did here was the same:
> just get the thing done.

There's a difference between agreeing to disagree and going ahead with a
majority solution, and not even bothering to see whether we can find
consensus and by not even replying to a message wondering about
consistency.

Greetings,

Andres Freund