checking rd_rules in RelationBuildDesc
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t47005psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 11:09 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t47005_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t47005_1 && git checkout t47005_1Patchset v1 (message #1) is on t47005_1
Hi,
(In light of commit 7b2ccc5e03bf16d1e1bbabca25298108c839ec52)
In RelationBuildDesc(), we have:
if (relation->rd_rel->relhasrules)
RelationBuildRuleLock(relation);
I wonder if we should check relation->rd_rules after the call
to RelationBuildRuleLock().
Your comment is appreciated.
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
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