Re: checking rd_rules in RelationBuildDesc

Поиск
Список
Период
Сортировка
От Ted Yu
Тема Re: checking rd_rules in RelationBuildDesc
Дата
Msg-id CALte62w04c3FULb5gnnidn5QVYHWQ6=THeD_uhC7eA6bX2xhrw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: checking rd_rules in RelationBuildDesc  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


On Fri, Nov 25, 2022 at 8:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ted Yu <yuzhihong@gmail.com> writes:
> I wonder if we should check relation->rd_rules after the call
> to RelationBuildRuleLock().

That patch is both pointless and wrong.  There is some
value in updating relhasrules in the catalog, so that future
relcache loads don't uselessly call RelationBuildRuleLock;
but we certainly can't try to do so right there.  That being
the case, making the relcache be out of sync with what's on
disk cannot have any good consequences.  The most likely
effect is that it would block later logic from fixing things
correctly.  There is logic in VACUUM to clean out obsolete
relhasrules flags (see vac_update_relstats), but I suspect
that would no longer work properly if we did this.

                        regards, tom lane
Hi,
Thanks for evaluating the patch.

The change was originating from what we have in RelationCacheInitializePhase3():

                if (relation->rd_rel->relhasrules && relation->rd_rules == NULL)
                {
                        RelationBuildRuleLock(relation);
                        if (relation->rd_rules == NULL)
                                relation->rd_rel->relhasrules = false;

FYI

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Bug in row_number() optimization
Следующее
От: Tom Lane
Дата:
Сообщение: Re: postgres_fdw: batch inserts vs. before row triggers