Re: Non-superuser subscription owners

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Non-superuser subscription owners
Date: 2021-11-29 04:13:41
Message-ID: CAA4eK1K1=DbXCNfA32urxZga6YxeiCvcTHvJu-+BtLCtVgqJ2w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 26, 2021 at 1:36 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> > as soon as possible instead of at the transaction
> > boundary.
>
> I don't understand why it's important to detect a loss of privileges
> faster than a transaction boundary. Can you elaborate?
>

The first reason is that way it would be consistent with what we can
see while doing the operations from the backend. For example, if we
revoke privileges from the user during the transaction, the results
will be reflected.
postgres=> Begin;
BEGIN
postgres=*> insert into t1 values(1);
INSERT 0 1
postgres=*> insert into t1 values(2);
ERROR: permission denied for table t1

In this case, after the first insert, I have revoked the privileges of
the user from table t1 and the same is reflected in the very next
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.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-11-29 04:42:19 Re: Deduplicate code updating ControleFile's DBState.
Previous Message Bharath Rupireddy 2021-11-29 04:09:59 Re: Synchronizing slots from primary to standby