Hi,
On 12/6/23 7:18 AM, shveta malik wrote:
> On Wed, Dec 6, 2023 at 10:56 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> I feel that is indirectly relying on the fact that the primary won't
>> advance logical slots unless physical standby has consumed data.
>
> Yes, that is the basis of this discussion.
Yes.
> But now on rethinking, if
> the user has not set 'standby_slot_names' on primary at first pace,
> then even if walreceiver on standby is down, slots on primary will
> keep on advancing
Oh right, good point.
> and thus we need to sync.
Yes and I think our current check "XLogRecPtrIsInvalid(WalRcv->latestWalEnd)"
in synchronize_slots() prevents us to do so (as I think WalRcv->latestWalEnd
would be invalid for a non started walreceiver).
> We have no check currently
> that mandates users to set standby_slot_names.
>
Yeah and OTOH unset standby_slot_names is currently the only
way for users to "force" advance failover slots if they want to (in case
say the standby is down for a long time and they don't want to block logical decoding
on the primary) as we don't provide a way to alter the failover property
(unless connecting with replication which sounds more like a hack).
>> Now,
>> it is possible that slot-sync worker lags behind and still needs to
>> sync more data for slots in which it makes sense for slot-sync worker
>> to be alive.
Right.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com