Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility. - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
Date
Msg-id CAA4eK1+_ynkOmG53dHDH+1XOsne0=+KUpjb_cbjk5eR5nTg0yA@mail.gmail.com
Whole thread Raw
In response to Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
List pgsql-hackers
On Sat, Mar 15, 2025 at 11:35 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Sat, Mar 15, 2025 at 4:52 PM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > On Fri, Mar 14, 2025 at 5:39 PM David G. Johnston
> > <david.g.johnston@gmail.com> wrote:
> > >
> > > On Tuesday, March 11, 2025, Peter Smith <smithpb2250@gmail.com> wrote:
> > >>
> > >>
> > >> Choice 3. Implement some option that has an argument saying what to delete
> > >>
> > >> Implement an option that takes some argument saying what objects to remove.
> > >>
> > >> Here, the current patch would be something like:
> > >> "--remove-target-objects=publications". In future, this option could
> > >> be enhanced to accept other values like
> > >> "--remove-target-objects=publications,subscriptions" etc.
> > >
> > >
> > > I’m changing my vote to option 3.  With a requirement that dropping is done post-recovery by the user via psql -
wejust provide the commands we would have executed in a script. 
> > >
> > > —prune-file=‘drop-commands.psql’
> > > —prune=publications
> > > —prune=subscriptions
> > > Etc…
> > >
> > > I’d rather do multiple specifications than commas separated.  It matches what we already do with databases, which
wasdone this way I suspect for the same reasons - length of the parameters value when we have: 
> > > Publications
> > > Slots
> > > Subscriptions
> > > Databases
> > > Roles
> > > Tablespaces
> > >
> >
>
> (I'm sorry, my previous post included a confusing typo. Here is the correction)
>
> OK. Here are some examples...
>
> style #1:
> --prune=Publications --prune=Slots --prune=Subscriptions
> --prune=Databases --prune=Tablespaces
>
> versus
>
> style #2:
> --prune=Publications,Slots,Subscriptions,Databases,Tablespaces
>
> David, I understand you are saying that you prefer style #1 because of
> the potentially cumbersome length of the csv value part of style #2 if
> there are many future object kinds (e.g.
> "Publications,Slots,Subscriptions,Databases,Tablespaces" in the above
> examples).
>

Style-1 sounds reasonable to me, but how exactly we want to do. One
idea is to have short and long switches like -r and
--remove_exiting_object=publication. The user would be allowed to give
multiple options like -r publications -r slots, etc.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Reducing the log spam
Next
From: Amit Kapila
Date:
Subject: Re: long-standing data loss bug in initial sync of logical replication