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
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 |