From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(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-15 06:15:58 |
Message-ID: | CAA4eK1+_ynkOmG53dHDH+1XOsne0=+KUpjb_cbjk5eR5nTg0yA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 15, 2025 at 11:35 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> On Sat, Mar 15, 2025 at 4:52 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
> > On Fri, Mar 14, 2025 at 5:39 PM David G. Johnston
> > <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > >
> > > On Tuesday, March 11, 2025, Peter Smith <smithpb2250(at)gmail(dot)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 - we just 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 was done 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-03-15 06:24:40 | Re: long-standing data loss bug in initial sync of logical replication |
Previous Message | Laurenz Albe | 2025-03-15 06:12:22 | Re: Reducing the log spam |