On Sun, 9 Mar 2025 at 03:27, Nathan Bossart wrote:
>
> On Sun, Mar 09, 2025 at 03:01:41AM +0530, Ayush Vatsa wrote:
> > Maybe we can move ahead with the patch if we can see no other concerns.
>
> I think we should allow some time in case others want to review the patch.
> I do see a concern upthre
Nathan Bossart writes:
> On Sat, Mar 08, 2025 at 05:17:40PM -0500, Tom Lane wrote:
>> ReindexIndex() faces this same problem and solves it with some
>> very complex code that manages to get the table's lock first.
> I noticed that amcheck's bt_index_check_internal() handles this problem,
> ...
>
On Sun, Mar 09, 2025 at 11:48:05AM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Sat, Mar 08, 2025 at 05:17:40PM -0500, Tom Lane wrote:
>>> ReindexIndex() faces this same problem and solves it with some
>>> very complex code that manages to get the table's lock first.
>
>> I noticed that
On Sat, Mar 08, 2025 at 05:17:40PM -0500, Tom Lane wrote:
> It bothers me a bit that this proposes to do something as complicated
> as pg_class_aclcheck on a table we have no lock on. As you say, the
> lock we hold on the index would prevent DROP TABLE, but that doesn't
> mean we won't have any is
> From a quick test and skim of the relevant
> code, I think your patch is fine, though
Thanks for reviewing.
> And IIUC
> DROP TABLE first acquires a lock on the table and its dependent objects
> (e.g., indexes) before any actual deletions, so AFAICT there's no problem
> with using it in pg_class
Nathan Bossart writes:
> I do see a concern upthread about increased deadlock risk [0], but your
> patch doesn't lock the table, but unless I'm wrong [1] (which is always
> possible), it doesn't need to lock it.
It bothers me a bit that this proposes to do something as complicated
as pg_class_acl
On Sun, Mar 09, 2025 at 03:01:41AM +0530, Ayush Vatsa wrote:
> Maybe we can move ahead with the patch if we can see no other concerns.
I think we should allow some time in case others want to review the patch.
I do see a concern upthread about increased deadlock risk [0], but your
patch doesn't lo
On Sat, Mar 08, 2025 at 08:34:40PM +0530, Ayush Vatsa wrote:
>> I'm wondering whether setting missing_ok to true is correct here. IIUC we
>> should have an AccessShareLock on the index, but I don't know if that's
>> enough protection.
>
> Since we are already opening the relation with rel = relat
> I'm wondering whether setting missing_ok to true is correct here. IIUC we
> should have an AccessShareLock on the index, but I don't know if that's
> enough protection.
Since we are already opening the relation with rel = relation_open(relOid,
AccessShareLock);,
if relOid does not exist, it wil
On Wed, Feb 19, 2025 at 03:53:48PM +0530, Ayush Vatsa wrote:
> It seems there's a general consensus that we should maintain a
> original design to support pg_prewarm, with a minor adjustment:
> when querying indexes, we should verify the privileges of the parent table.
>
> I´ve attached a patch fo
Added the CF entry for the same -
https://commitfest.postgresql.org/patch/5583/
Regards,
Ayush Vatsa
SDE AWS
>
Hello Everyone,
It seems there's a general consensus that we should maintain a
original design to support pg_prewarm, with a minor adjustment:
when querying indexes, we should verify the privileges of the parent table.
I’ve attached a patch for this, which includes some test cases as well.
Let me
On Tue, Feb 18, 2025 at 11:30 AM Tom Lane wrote:
> I have no objection to it, but I wasn't as entirely convinced
> as you are that it's the only plausible answer.
Hmm, OK.
> One specific thing I'm slightly worried about is that a naive
> implementation would probably cause this function to lock
Robert Haas writes:
> That is a +1 for the specific design of "check SELECT on the index's
> table". I don't want to be closed-minded: if you have some strong
> reason for believing that's the wrong thing to do, I'm all ears.
> However, I'm presently of the view that it is exactly the right thing
On Tue, Feb 18, 2025 at 11:02 AM Tom Lane wrote:
> Is that a +1 for the specific design of "check SELECT on the index's
> table", or just a +1 for changing something here?
That is a +1 for the specific design of "check SELECT on the index's
table". I don't want to be closed-minded: if you have so
Robert Haas writes:
> On Mon, Feb 17, 2025 at 5:18 PM David G. Johnston
> wrote:
>>> I have a very vague recollection that we concluded that SELECT
>>> privilege was a reasonable check because if you have that you
>>> could manually prewarm by reading the table. That would lead
>>> to the conclu
On Mon, Feb 17, 2025 at 5:18 PM David G. Johnston
wrote:
>> I have a very vague recollection that we concluded that SELECT
>> privilege was a reasonable check because if you have that you
>> could manually prewarm by reading the table. That would lead
>> to the conclusion that the minimal fix is
On Mon, Feb 17, 2025 at 3:02 PM Tom Lane wrote:
> Ayush Vatsa writes:
> > Thanks Robert for confirming, let me submit a patch to fix the same.
>
> Well, the first thing you need is consensus on what the behavior
> should be instead.
>
> I have a very vague recollection that we concluded that SEL
Ayush Vatsa writes:
> Thanks Robert for confirming, let me submit a patch to fix the same.
Well, the first thing you need is consensus on what the behavior
should be instead.
I have a very vague recollection that we concluded that SELECT
privilege was a reasonable check because if you have that
> I'm not sure if I'd call that a "design". Sounds like I just made a
> mistake here.
Thanks Robert for confirming, let me submit a patch to fix the same.
Regards
Ayush Vatsa
ADE AWS
On Mon, Feb 17, 2025 at 2:57 PM Tom Lane wrote:
> Ayush Vatsa writes:
> >> As it stands, a superuser can prewarm an index (because she bypasses all
> >> privilege checks including this one), but nobody else can.
>
> > That's not fully true. Any role can prewarm an index if the role has the
> > co
Ayush Vatsa writes:
>> As it stands, a superuser can prewarm an index (because she bypasses all
>> privilege checks including this one), but nobody else can.
> That's not fully true. Any role can prewarm an index if the role has the
> correct privileges.
Ah, right. An index will have null pg_cl
> As it stands, a superuser can prewarm an index (because she bypasses all
> privilege checks including this one), but nobody else can.
That's not fully true. Any role can prewarm an index if the role has the
correct privileges.
postgres=# GRANT CREATE ON SCHEMA PUBLIC TO alpha;
GRANT
postgres=# SE
23 matches
Mail list logo
