Re: checking rd_rules in RelationBuildDesc

From: Ted Yu <yuzhihong(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: dean(dot)a(dot)rasheed(at)gmail(dot)com, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: checking rd_rules in RelationBuildDesc
Date: 2022-11-25 16:22:58
Message-ID: CALte62w04c3FULb5gnnidn5QVYHWQ6=THeD_uhC7eA6bX2xhrw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 25, 2022 at 8:17 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Ted Yu <yuzhihong(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-11-25 16:57:33 Re: postgres_fdw: batch inserts vs. before row triggers
Previous Message Tom Lane 2022-11-25 16:19:09 Re: Bug in row_number() optimization