Re: should ConstraintRelationId ins/upd cause relcache invals?
От | Tom Lane |
---|---|
Тема | Re: should ConstraintRelationId ins/upd cause relcache invals? |
Дата | |
Msg-id | 22800.1548112471@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: should ConstraintRelationId ins/upd cause relcache invals? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: should ConstraintRelationId ins/upd cause relcache invals?
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.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
В списке pgsql-hackers по дате отправления: