Re: running logical replication as the subscription owner
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>
Date: 2023-03-31T19:17:06Z
Lists: pgsql-hackers
On Fri, Mar 31, 2023 at 3:36 AM Jeff Davis <pgsql@j-davis.com> wrote: > That's moving the goalposts a little, though: > > "Some concern was expressed ... might break things that are currently > working..." > > https://www.postgresql.org/message-id/CA+TgmoaE35kKS3-zSvGiZszXP9Tb9rNfYzT=+fO8Ehk5EDKrag@mail.gmail.com > > If the original use case was "don't break stuff", I think patch 0002 > solves that, and we don't need this special case in 0001. Would you > agree with that statement? I think that's too Boolean. The special case in 0001 is a better solution for the cases where it works. It's both more granular and more convenient. The fact that you might be able to get by with 0002 doesn't negate that. > > But I imagine CREATE SUBSCRIPTION being used either by > > superusers or by people who already have those role grants anyway, > > because I imagine replication as something that a highly privileged > > user configures on behalf of everyone who uses the system. And in > > that > > case those role grants aren't something new that you do specifically > > for logical replication - they're already there because you need them > > to administer stuff. Or you're the superuser and don't need them > > anyway. > > Did the discussion drift back towards the SET ROLE in the other > direction? I thought we had settled that in v16 we would require that > the subscription owner can SET ROLE to the table owner (as in your > current 0001), but that we could revisit it later. Yeah, I think that's what we agreed. I'm just saying that I'm not as concerned about that design as you are, and encouraging you to maybe not be quite so dismayed by it. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Honor run_as_owner option in tablesync worker.
- a83edeaf684a 16.0 landed
-
Document new pg_subscription columns.
- bc25d6c54a00 16.0 landed
-
Add a run_as_owner option to subscriptions.
- 482675987bcd 16.0 landed
-
Perform logical replication actions as the table owner.
- 1e10d49b65d6 16.0 landed
-
Add new predefined role pg_create_subscription.
- c3afe8cf5a1e 16.0 cited
-
Respect permissions within logical replication.
- a2ab9c06ea15 15.0 cited
-
Empty search_path in logical replication apply worker and walsender.
- 11da97024abb 14.0 cited
-
Empty search_path in Autovacuum and non-psql/pgbench clients.
- 582edc369cdb 11.0 cited