public inbox for pgsql-hackers@postgresql.org  
help / color / mirror / Atom feed
From: Fujii Masao <masao.fujii@gmail.com>
To: Nisha Moond <nisha.moond412@gmail.com>
Cc: Peter Smith <smithpb2250@gmail.com>
Cc: David G. Johnston <david.g.johnston@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_createsubscriber: Fix incorrect handling of cleanup flags
Date: Fri, 22 May 2026 14:27:54 +0900
Message-ID: <CAHGQGwH6MtZ9dN-zeF7SjqzCmP-e4DKERYWp9zYEofUnqb_-Kg@mail.gmail.com> (raw)
In-Reply-To: <CABdArM4gOAVKayZvTa-pyyCY7519zWe7Hx4cg_enEr32JdS6xQ@mail.gmail.com>
References: <CABdArM5V9QKK1PkLY9dpgAcZa3kUp84-wPqPovxvdLOri4=69w@mail.gmail.com>
	<CAKFQuwaqWa3tRNMaRYpa4jE7BVSMb1tPTeiwM9GE7781nKOPEQ@mail.gmail.com>
	<CABdArM5WZesYgUL_XMQHvHA9Q78vHaMuNtNdYc0Kas7acNwE8Q@mail.gmail.com>
	<CAHut+PsXt4sLRZSWTr4g5ro-d1bJqKC5YpQNzTTPaPsE+Wvb+A@mail.gmail.com>
	<CABdArM4gOAVKayZvTa-pyyCY7519zWe7Hx4cg_enEr32JdS6xQ@mail.gmail.com>

On Tue, May 12, 2026 at 7:56 PM Nisha Moond <nisha.moond412@gmail.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






reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: masao.fujii@gmail.com, nisha.moond412@gmail.com, smithpb2250@gmail.com, david.g.johnston@gmail.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: pg_createsubscriber: Fix incorrect handling of cleanup flags
  In-Reply-To: <CAHGQGwH6MtZ9dN-zeF7SjqzCmP-e4DKERYWp9zYEofUnqb_-Kg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox