Horton
Menu

Re: running logical replication as the subscription owner

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>
Date: 2023-04-03T19:14:33Z
Lists: pgsql-hackers 
On Mon, 2023-04-03 at 10:26 -0400, Robert Haas wrote:
> Not very much. I think the biggest risk is user confusion, but I
> don't
> think that's a huge risk because I don't think this scenario will
> come
> up very often. Also, it's kind of hard to imagine that there's a
> security model here which never does anything potentially surprising.

Alright, let's just proceed as-is then. I believe these patches are a
major improvement to the usability of logical replication and will put
up with the weirdness. I wanted to understand better why it's there,
and I'm not sure I fully do, but we'll have more time to discuss later.

Regards,
	Jeff Davis

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Honor run_as_owner option in tablesync worker.

  2. Document new pg_subscription columns.

  3. Add a run_as_owner option to subscriptions.

  4. Perform logical replication actions as the table owner.

  5. Add new predefined role pg_create_subscription.

  6. Respect permissions within logical replication.

  7. Empty search_path in logical replication apply worker and walsender.

  8. Empty search_path in Autovacuum and non-psql/pgbench clients.