Re: running logical replication as the subscription owner

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: running logical replication as the subscription owner
Date: 2023-03-31 19:17:06
Message-ID: CA+Tgmobxu78xhtKrCU+tjJmXXv_mgzVad6RsOo8W0QEEyA3Tiw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 31, 2023 at 3:36 AM Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-03-31 19:25:13 Re: BUG #17877: Referencing a system column in a foreign key leads to incorrect memory access
Previous Message Melanie Plageman 2023-03-31 19:09:21 Re: Should vacuum process config file reload more often