Re: CREATE SUBSCRIPTION -- add missing tab-completes

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: CREATE SUBSCRIPTION -- add missing tab-completes
Date: 2023-04-08 05:38:57
Message-ID: CAA4eK1LgEyfAngJ=h=6umU2GTmPH+cNc-_K6q09ry2NRPkMWPA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 7, 2023 at 6:59 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Fri, Apr 7, 2023 at 6:10 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Apr 7, 2023 at 1:12 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > >
> >
> > Do you mean that because 'password_required' is used each time we make
> > a connection to a publisher during replication, it should be in the
> > second category? If so, slot_name is also used during the start
> > replication each time.
>
> I think that parameters used by the backend process when performing
> CREATE SUBSCRIPTION belong to the first category. And other parameters
> used by apply workers and tablesync workers belong to the second
> category. Since slot_name is used by both I'm not sure it should be in
> the second category, but password_requried seems to be used by only
> apply workers and tablesync workers, so it should be in the second
> category.
>

Hmm, don't we use the option "password_requried" during CREATE
SUBSCRIPTION when we have to connect? The second category is more
about parameters that define the replication behavior so it is not
clear to me how this falls in that category. See the initial
discussion which led to the current situation [1]. Anyway, for now, I
have just committed the fix for the datatype as we have not reached a
consensus on this one.

> >
> > BTW, do we need to check one or both of these parameters in
> > maybe_reread_subscription() where we "Exit if any parameter that
> > affects the remote connection was changed."
>
> As for run_as_owner, since we can dynamically switch the behavior I
> think we don't need to reconnect. I'm not really sure about
> password_required. From the implementation point of view, we don't
> need to reconnect. Even if password_required is changed from false to
> true, the apply worker already has the established connection. If it's
> changed from true to false, we might not want to reconnect. I think we
> need to consider it from the security point of view while checking the
> motivation that password_required was introduced. So probably it's
> better to discuss it on the original thread.
>

Agreed and responded to the original thread [2].

[1] - https://www.postgresql.org/message-id/CAA4eK1Kmu74xHk2jcHTmKq8HBj3xK6n%3DRfiJB6dfV5zVSqqiFg%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/CAA4eK1%2Bz9UDFEynXLsWeMMuUZc1iQkRwj2HNDtxUHTPo-u1F4A%40mail.gmail.com

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-04-08 06:04:08 Re: Direct I/O
Previous Message Amit Kapila 2023-04-08 05:34:53 Re: Non-superuser subscription owners