Re: should ConstraintRelationId ins/upd cause relcache invals?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, 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 23:33:26
Message-ID: 20190121233326.szmpsnquxpccufer@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-01-21 18:14:31 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > 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.
>
> I don't think that's relevant. The issues there were about whether
> a pg_index row update ought to cause an invalidation of the relcache
> entry for the index's table (not the one for the index, which it
> already takes care of). That seems very questionable to me --- the
> potentially-invalidatable info ought to be in the index's relcache entry,
> not its parent table's entry, IMO.

Well, we've plenty of information about indexes in the table's
relcache. Among other things, the list of indexes, bitmaps of indexed
attributes, which index is the primary key, etc is all maintained
there... So I don't really see a material difference between the
constraint and the index case. You can make some arguments about
superfluous invals, true. I don't see why rd_indexlist et al is
materially different from rd_fkeylist.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-01-21 23:38:25 Re: should ConstraintRelationId ins/upd cause relcache invals?
Previous Message Alvaro Herrera 2019-01-21 23:30:20 Re: problems with foreign keys on partitioned tables