Hi,
On 12/6/23 11:58 AM, shveta malik wrote:
On Wed, Dec 6, 2023 at 3:00 PM Drouvot, Bertrand
<bertranddrouvot...@gmail.com> wrote:
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).
But I think we do not need to deal with the case that walreceiver is
not started at all on standby. It is always started. Walreceiver not
getting started or down for long is a rare scenario. We have other
checks too for 'latestWalEnd' in slotsync worker and I think we should
retain those as is.
Agree to not deal with the walreceiver being down for now (we can
still improve that part later if we encounter the case in the real
world).
Might be worth to add comments in the code (around the WalRcv->latestWalEnd
checks) that no "lagging" sync are possible if the walreceiver is not started
though?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
