Re: Synchronizing slots from primary to standby - Mailing list pgsql-hackers

Hi,

On 12/6/23 11:58 AM, shveta malik wrote:
> On Wed, Dec 6, 2023 at 3:00 PM Drouvot, Bertrand
> <bertranddrouvot.pg@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.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).
>>
> 
> 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