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

From David G. Johnston
Subject Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
Date
Msg-id CAKFQuwZ4tudu9MMJrLJjhSzQeRhAdXEMxAFf2R+UKXK_9g7bjg@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>)
List pgsql-hackers
On Mon, Mar 10, 2025 at 5:00 PM Peter Smith <smithpb2250@gmail.com> wrote:

6.
The test code remains difficult to review because I can't see the
forest for the trees due to the dozens of S->S1 node name changes.
These name changes are unrelated to the new feature so please separate
them into a different prerequisite patch so we can just focus on what
changes were made just for --drop-all-publications. I know you already
said you are working on it [1-#7], but multiple patch versions have
been posted since you said that.


I don't see the point of renaming S to S1.

I also don't get re-defining the existing S tests to include --drop-all-publications and then go and add a new test that excludes --drop-all-publications.

Just name the new subscriber D (or pick some other random letter, it isn't like we are encouraging meaningful variable names here) and have it test the behavior of --drop-all-publications.  Given the existing design, the introduction of two new user publications on P initially shouldn't impact existing tests (and if it does, seeing that change in the existing tests would be a good thing).  An extra check or two against S should suffice to prove non-deletion.

In short, this probably needn't touch any existing tests, just the shared setup.

Also, can we explain why it is important to use --verbose --verbose?  Obviously it shows more information, that what repeating --verbose is defined to do. (Sure, that isn't new to this patch.)  But why is it important that this specific command use it when none of the others do?

David J.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Not-terribly-safe checks for CRC intrinsic support
Next
From: Thomas Munro
Date:
Subject: Re: Available disk space per tablespace