Hi,
On 12/6/23 7:18 AM, shveta malik wrote:
On Wed, Dec 6, 2023 at 10:56 AM Amit Kapila <amit.kapil...@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
