Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Shubham Khanna <khannashubham1197(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
Date: 2025-03-14 15:26:32
Message-ID: CAKFQuwZndrQ1K86x24SGZjmxzVNRYJ-G6e_VmEi0-rcUdXEOmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 14, 2025 at 12:26 AM Zhijie Hou (Fujitsu) <
houzj(dot)fnst(at)fujitsu(dot)com> wrote:

> For logical replication, there is a frequent need to automatically delete
> all
> objects (including publications) on replicas that are no longer needed.
> This
> requirement comes from a common use case in logical replication, which is
> to
> replicate only a subset of database objects.

I don't see us implementing an API to provide an alternative to "ALL
TABLES"...

Personally, I am uncertain about
> the use case for retaining only some of the publications while dropping
> others.
>

To assume there is nothing between All or None seems unwise even if we
cannot imagine what that may be.

> Besides, I am unsure if the rationale behind pg_upgrade's output script is
> applicable here.

Yeah, I probably shouldn't have mentioned it. I don't need it to explain
or support my case.

I think the option proposed in this thread is not to handle the
> version mismatch between the publisher and the subscriber.

Certainly not given that this requires a physical standby as a base and
those are not cross-major-version capable.

Overall,
> I favor automatically deleting publications rather than offering a script
> for
> manual execution.
>
>
I'm done arguing the counter-point to this. I cannot give this a +1 unless
the DBA is given a chance to review and edit the drop commands that we
create. But as of now I'm in the minority and this has a committer willing
to proceed without this capability. I take some comfort in that it seems
at least if they use --dry-run they can see what objects will be dropped.
But the editor capability seems more useful. There is always v19 and
beyond; at least nothing here precludes adding such a feature in the future.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rafael Thofehrn Castro 2025-03-14 15:36:34 Re: Proposal: Progressive explain
Previous Message Nathan Bossart 2025-03-14 15:21:30 Re: PATCH: warn about, and deprecate, clear text passwords