Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Peter Smith <smithpb2250(at)gmail(dot)com>, Shubham Khanna <khannashubham1197(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
Date: 2025-03-12 06:41:42
Message-ID: CAA4eK1J-Xp45A9JF7OK=Uu8edMPHZ7a=Lz958_ooZYA2PG+0EQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 12, 2025 at 10:42 AM David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> On Tuesday, March 11, 2025, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>
>> On Wed, Mar 12, 2025 at 9:43 AM David G. Johnston
>> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>> >
>> > I’m honestly question how much value this provides - no improvement here seems like a viable choice. Let them issue the drop commands they desire manually. This doesn’t feel like something one should/would automate.
>> >
>>
>> There is a good chance of mistakenly dropping the required objects
>> manually after the subscriber is converted. One can mistakenly drop
>> the required publication unless they have some strict rule to do it
>> immediately after the tool has converted standby to subscriber.
>
>
> If you are referring to “step 6”, that bypasses this requirement because pg_createsubscriber created it, knows the exact name, and it is well defined why that specific publication should be removed.
>

I am not referring to step 6. I am saying that users could have
created the publications by themselves after converting the standby to
subscriber. It won't be convenient to remember those and distinguish
them from the existing publications as there won't be any particular
pattern. The point is that there is a chance of misuse or data loss
with manual steps, which is not there if done via this option.

>>
>> Providing the commands via file is a way, but as a user, I would
>> prefer to get the things done automatically via a tool instead of me
>> doing it afterward unless there is no other way..
>>
>
> Given that the fallback position is to restore the physical standby and do the transformation again I suppose it isn’t too bad if we or the user messes up a run.
>

As mentioned above, there is always a chance of data loss if it is
done manually, even if we restore to a backup of physical standby.

>
But you can still get the tool to basically do it for you
automatically by just blindly sending the through psql. The people
who want the safety net have no option. I suspect the percentage of
DBAs that would appreciate the option would be meaningful. After all,
we felt it necessary to add a —dry-run option.
>

This could be another option, but I feel an option with a tool is more
meaningful than allowing users to do afterward steps.

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2025-03-12 06:51:08 Re: CRC32C Parallel Computation Optimization on ARM
Previous Message Ashutosh Sharma 2025-03-12 06:40:30 Re: Orphaned users in PG16 and above can only be managed by Superusers