From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ayush Vatsa <ayushvatsa1810(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Clarification on Role Access Rights to Table Indexes |
Date: | 2025-10-10 18:31:03 |
Message-ID: | 31a67adbb10b85ff7cddeafe75b9f6505c902e57.camel@j-davis.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Fri, 2025-10-10 at 11:26 -0500, Nathan Bossart wrote:
> On Thu, Oct 09, 2025 at 04:18:03PM -0500, Nathan Bossart wrote:
> > There's a similar pattern in get_rel_from_relname() in dblink.c,
> > which also
> > seems to only be used with an AccessShareLock (like pg_prewarm).
> > My best
> > guess from reading lots of code, commit messages, and old e-mails
> > in the
> > archives is that the original check-privileges-before-locking work
> > was
> > never completed.
Interesting, thank you for the analysis.
> > I'm currently leaning towards continuing with v4 of the patch set.
> > 0001
> > and 0003 are a little weird in that a concurrent change could lead
> > to a
> > "could not find parent table" ERROR, but IIUC that is an extremely
> > remote
> > possibility.
>
> After sleeping on it, I still think this is the right call. In any
> case,
> I've spent way too much time on this stuff, so I plan to commit the
> attached soon.
I'm OK with that. v5-0001 is an improvement over the current situation.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2025-10-10 18:42:57 | Re: another autovacuum scheduling thread |
Previous Message | Jeff Davis | 2025-10-10 18:28:42 | Re: new environment variable INITDB_LOCALE_PROVIDER |
From | Date | Subject | |
---|---|---|---|
Previous Message | Nathan Bossart | 2025-10-10 16:26:08 | Re: Clarification on Role Access Rights to Table Indexes |