Re: should ConstraintRelationId ins/upd cause relcache invals?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
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:14:31
Message-ID: 22800.1548112471@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. Here, however, it's clear which
relcache entry is dependent on those pg_constraint rows (as long as Alvaro
got it right about whether to inval conrelid or confrelid ...), and
that it is indeed so dependent.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-01-21 23:17:01 Re: Changing SQL Inlining Behaviour (or...?)
Previous Message Alvaro Herrera 2019-01-21 23:12:30 Re: problems with foreign keys on partitioned tables