On Tue, May 12, 2026 at 7:56 PM Nisha Moond <[email protected]> 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
