Re: Check for existing replication slot in pg_createsubscriber

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Zane Duffield <duffieldzane(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Check for existing replication slot in pg_createsubscriber
Date: 2025-06-30 03:15:29
Message-ID: CAA4eK1JuC0CwNRhncyhU6T73gRA4obz0BR2atxsT+xgPZkv93w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 30, 2025 at 8:37 AM Zane Duffield <duffieldzane(at)gmail(dot)com> wrote:
>
> On Mon, Jun 30, 2025 at 1:01 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> 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 while using this tool, or is it a
>> code-level observation?
>
>
> In my case the --subscription and --replication-slot options are used to control the identifiers; the conflict was the user's fault, not the program's.
>

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.
Otherwise, each such check adds an additional network round-trip.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniil Davydov 2025-06-30 03:21:07 Replace magic numbers with strategy numbers for B-tree indexes
Previous Message Zane Duffield 2025-06-30 03:07:40 Re: Check for existing replication slot in pg_createsubscriber