Re: Synchronizing slots from primary to standby

Hi,

On 11/9/23 3:41 AM, Amit Kapila wrote:
> On Wed, Nov 8, 2023 at 8:09 PM Drouvot, Bertrand
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>>
>>> Unrelated to above, if there is a user slot on standby with the same
>>> name which the slot-sync worker is trying to create, then shall it
>>> emit a warning and skip the sync of that slot or shall it throw an
>>> error?
>>>
>>
>> I'd vote for emit a warning and move on to the next slot if any.
>>
>
> But then it could take time for users to know the actual problem and
> they probably notice it after failover.

Right, that's not appealing....

OTOH the slot has already been created manually on the standby so there is
probably already a "use case" for it (that is probably unrelated to the
failover story then).

In V32, the following states have been introduced:

"
'n': none for user slots,
'i': sync initiated for the slot but waiting for primary to catch up.
'r': ready for periodic syncs.
"

Should we introduce a new state that indicates that a sync slot creation
has failed because the slot already existed? That would probably
be simple to monitor instead of looking at the log file.

> OTOH, if we throw an error
> then probably they will come to know earlier because the slot sync
> mechanism would be stopped.

Right.

> Do you have reasons to prefer giving a
> WARNING and skipping creating such slots?

My idea was that with a WARNING it won't block others slot creation (if any).

> I expect this WARNING to
> keep getting repeated in LOGs because the consecutive sync tries will
> again generate a WARNING.
>

Yes.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com