Dear Amit, Zane,
> Okay, I find your case a good reason to add such a check, apart from
> making the code consistent in terms of these checks. One thing I was
> thinking is whether it makes sense to add these checks only in
> --dry-run mode because we normally don't expect such conflicts.
> Otherw
On Mon, Jun 30, 2025 at 1:15 PM Amit Kapila wrote:
> One thing I was
> thinking is whether it makes sense to add these checks only in
> --dry-run mode because we normally don't expect such conflicts.
> Otherwise, each such check adds an additional network round-trip.
>
I did wonder why it bother
On Mon, Jun 30, 2025 at 8:37 AM Zane Duffield wrote:
>
> On Mon, Jun 30, 2025 at 1:01 PM Amit Kapila wrote:
>>
>>
>> I see the difference you are pointing to. Ideally, the checks should
>> be the same unless there is a specific reason for them to be
>> different, which should be mentioned in the
On Mon, Jun 30, 2025 at 1:01 PM Amit Kapila wrote:
>
> I see the difference you are pointing to. Ideally, the checks should
> be the same unless there is a specific reason for them to be
> different, which should be mentioned in the comments. BTW, do you see
> any problems due to name conflicts w
On Fri, Jun 27, 2025 at 1:13 PM Zane Duffield wrote:
>
> Hackers,
>
> I noticed in testing and usage that pg_createsubscriber doesn't check for an
> existing replication slot before attempting to create one, whereas it *does*
> check for existing publications.
>
I see the difference you are poi
Hackers,
I noticed in testing and usage that pg_createsubscriber doesn't check for
an existing replication slot before attempting to create one, whereas it
*does* check for existing publications.
If it were to check for an existing replication slot, then the --dry-run
mode would be able to detect
