Re: Non-superuser subscription owners - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Non-superuser subscription owners
Date
Msg-id 785e8b8ab06f123cf754862557bd3171aeba4d65.camel@j-davis.com
Whole thread Raw
In response to Re: Non-superuser subscription owners  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Non-superuser subscription owners
List pgsql-hackers
On Mon, 2021-11-29 at 09:43 +0530, Amit Kapila wrote:
> The first reason is that way it would be consistent with what we can
> see while doing the operations from the backend.

Logical replication is not interactive, so it doesn't seem quite the
same.

If you have a long running INSERT INTO SELECT or COPY FROM, the
permission checks just happen at the beginning. As a user, it wouldn't
surprise me if logical replication was similar.

> operation. Another reason is to make behavior predictable as users
> can
> always expect when exactly the privilege change will be reflected and
> it won't depend on the number of changes in the transaction.

This patch does detect ownership changes more quickly (at the
transaction boundary) than the current code (only when it reloads for
some other reason). Transaction boundary seems like a reasonable time
to detect the change to me.

Detecting faster might be nice, but I don't have a strong opinion about
it and I don't see why it necessarily needs to happen before this patch
goes in.

Also, do you think the cost of doing maybe_reread_subscription() per-
tuple instead of per-transaction would be detectable? If we lock
ourselves into semantics that detect changes quickly, it will be harder
to optimize the per-tuple path later.

Regards,
    Jeff Davis





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Windows: Wrong error message at connection termination
Next
From: Tom Lane
Date:
Subject: Re: Lots of memory allocated when reassigning Large Objects