Re: pg_createsubscriber: Fix incorrect handling of cleanup flags

On Tue, May 12, 2026 at 7:56 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
> Let me first briefly explain why this patch still holds:
> The made_publication and made_replslot are publisher-side cleanup
> flags. They are checked only in cleanup_objects_atexit(), which
> executes at most once and connects to the publisher to remove objects
> created by the tool. They have no inherent relationship to the
> subscriber.
> That said, check_and_drop_publications() always operates on the
> subscriber, so resetting made_publication because of a failure on the
> subscriber side, when that same flag is later used for publisher-side
> cleanup, does not seem correct to me as it could incorrectly skip the
> required cleanup. A failure on one server should not affect cleanup
> decisions for another server. The same is true for the made_replslot
> flag in respective code.
>
> After looking further, I noticed that since a recent commit
> 85ddcc2[3], check_and_drop_publications() also reads made_publication
> to decide whether the subscriber-side inherited publication should be
> dropped or preserved. In that sense, the dual usage of the flag looks
> valid and continues to work correctly with my patch.
>
> Also, after checking on pg_head, I don’t think there is a possibility
> of a double-drop on the subscriber side. Either all publications are
> dropped in the if (drop_all_pubs) block when "--remove=publications"
> is specified, or by default the else block drops only dbinfo->pubname
> (the FOR ALL TABLES publication). The if (made_publication) condition
> simply guards against dropping a pre-existing publication. I don’t see
> an issue there, but please let me know if I’m missing something.

Thanks for the analysis of this issue!

Barring any objections, I will commit the patch and backpatch it to v17.

Regards,

--
Fujii Masao