Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
| От | David G. Johnston |
|---|---|
| Тема | Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility. |
| Дата | |
| Msg-id | CAKFQuwb-4C3L37JbnN7R-AtVE71c+Xy1tTbA=QaTrDzEJzTEEg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility. (Peter Smith <smithpb2250@gmail.com>) |
| Ответы |
Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
|
| Список | pgsql-hackers |
On Tue, Mar 11, 2025 at 12:20 AM Peter Smith <smithpb2250@gmail.com> wrote:
Unfortunately, we are spinning in circles a bit trying to come up with
a good way to represent the option needed for this, while at the same
time trying to be future-proof. I see 3 choices...
======
Choice 1. Generic option
Implement a single boolean option to remove everything.
Do you have any thoughts on what kind of option is best here?
Option 1 by far. Though personally I'd rather do something like what pg_upgrade does and output a script with drop commands that can be executed via psql instead of having pg_createsubscriber execute said commands. I'd call it "pruning the target".
Any automated bash script I'd write would just do:
pg_createsubscriber ... --prune-target-script=prune.sql
psql --file prune.sql
And if I'm working interactively I'd want to spend the extra minute or so reviewing the commands in prune.sql to make sure I know what is going away. I can also edit said file, or use something like grep, if I want to limit what is dropped.
In particular any database that isn't turned into a logical replica would be added to this list; in addition to all the publication/subscription stuff that is likely broken at this point.
David J.
В списке pgsql-hackers по дате отправления: