Re: Invalidate the subscription worker in cases where a user loses their superuser status - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Invalidate the subscription worker in cases where a user loses their superuser status
Date
Msg-id CAA4eK1KbH6Peet1_P=ZDrNtRvNDLAZU4KNaLV44oNh75vYUABQ@mail.gmail.com
Whole thread Raw
In response to Re: Invalidate the subscription worker in cases where a user loses their superuser status  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Invalidate the subscription worker in cases where a user loses their superuser status  (vignesh C <vignesh21@gmail.com>)
Re: Invalidate the subscription worker in cases where a user loses their superuser status  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Sep 27, 2023 at 6:58 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Tue, Sep 26, 2023 at 11:57 PM vignesh C <vignesh21@gmail.com> wrote:
> >
> > On Tue, 26 Sept 2023 at 13:03, Peter Smith <smithpb2250@gmail.com> wrote:
> > >
> > > Here are some comments for patch v2-0001.
> > >
> > > ======
> > > src/backend/replication/logical/worker.c
> > >
> > > 1. maybe_reread_subscription
> > >
> > > ereport(LOG,
> > >         (errmsg("logical replication worker for subscription \"%s\"
> > > will restart because of a parameter change",
> > >                 MySubscription->name)));
> > >
> > > Is this really a "parameter change" though? It might be a stretch to
> > > call the user role change a subscription parameter change. Perhaps
> > > this case needs its own LOG message?
> >
> > When I was doing this change the same thought had come to my mind too
> > but later I noticed that in case of owner change there was no separate
> > log message. Since superuser check is somewhat similar to owner
> > change, I felt no need to make any change for this.
> >
>
> Yeah, I had seen the same already before my comment. Anyway, YMMV.
>

But OTOH, the owner of the subscription can be changed by the Alter
Subscription command whereas superuser status can't be changed. I
think we should consider changing the message for this case.

BTW, do we want to backpatch this patch? I think we should backatch to
PG16 as it impacts password_required functionality. Before this patch
even if the subscription owner's superuser status is lost, it won't
use a password for connection till the server gets restarted or the
apply worker gets restarted due to some other reason. What do you
think?

Adding Jeff and Robert to see what is their opinion on whether we
should backpatch this or not.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: [PGdocs] fix description for handling pf non-ASCII characters
Next
From: David Rowley
Date:
Subject: Re: Use virtual tuple slot for Unique node