Re: Add support for specifying tables in pg_createsubscriber.

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Euler Taveira <euler(at)eulerto(dot)com>
Cc: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Shubham Khanna <khannashubham1197(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add support for specifying tables in pg_createsubscriber.
Date: 2025-09-12 05:05:09
Message-ID: CAA4eK1LJ8VmdN0zmjh-JJc4XRZ-AVMnvTau1KP9L2+GdbTVFXQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 11, 2025 at 6:34 PM Euler Taveira <euler(at)eulerto(dot)com> wrote:
>
> On Tue, Sep 9, 2025, at 11:34 PM, Zhijie Hou (Fujitsu) wrote:
> > On Wednesday, September 3, 2025 9:58 AM Peter Smith
> > <smithpb2250(at)gmail(dot)com> wrote:
> >>
> >> AFAICT, these problems don't happen if you allow a reinterpretation of
> >> --publication switch like Euler had suggested [1]. The dry-run logs
> >> should make it clear whether an existing publication will be reused or
> >> not, so I'm not sure even that the validation code (checking if the
> >> publication exists) is needed.
> >>
> >> Finally, I think the implementation might be simpler too -- e.g. fewer
> >> rules/docs needed, no option conflict code needed.
> >
> > I'm hesitant to directly change the behavior of --publication, as it seems
> > unexpected for the command in the new version to silently use an existing
> > publication when it previously reported an ERROR. Although the number of users
> > relying on the ERROR may be small, the change still appears risky to me.
> >
>
> I don't buy this argument. Every feature that is not supported emits an error.
> You can interpret it as (a) we don't support using existing publications until
> v18 but we will start support it from now on or (b) it is a hard error that we
> shouldn't allow, hence, stop now. I would say this case is (a) rather than (b).
>

Yeah, I am also not sure that it is worth adding a new option to save
backward compatibility for this option. It seems intuitive to use
existing publications when they exist, though we should clearly
document it.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Efrain J. Berdecia 2025-09-12 05:14:43 Re: New recovery_target_timeline=primary option
Previous Message Michael Paquier 2025-09-12 05:04:33 Re: Incorrect logic in XLogNeedsFlush()