Hi,
On 11/9/23 3:41 AM, Amit Kapila wrote:
> On Wed, Nov 8, 2023 at 8:09 PM Drouvot, Bertrand
> <bertranddrouvot.pg@gmail.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
