Re: Synchronizing slots from primary to standby

Hi,

On 12/5/23 11:29 AM, shveta malik wrote:
> On Tue, Dec 5, 2023 at 2:18 PM Drouvot, Bertrand
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>> Wouldn't that make sense to move it once we are sure that
>> walrcv_startstreaming() returns true and first_stream is true, here?
>>
>> "
>> if (first_stream)
>> + {
>> ereport(LOG,
>> (errmsg("started streaming WAL from primary at %X/%X on timeline %u",
>> LSN_FORMAT_ARGS(startpoint), startpointTLI)));
>> + SpinLockAcquire(&walrcv->mutex);
>> + walrcv->walRcvState = WALRCV_STREAMING;
>> + SpinLockRelease(&walrcv->mutex);
>> + }
>> "
>>
>
> Yes, it makes sense and is the basis for current slot-sync worker
> changes being discussed.

I think this change deserves its own dedicated thread and patch, does
that make sense?

If so, I'll submit one.

>>
>> 2) and 3) looks good to me but with a check on walrcv->walRcvState
>> looking for WALRCV_STREAMING state instead of looking for a non null
>> WalRcv->pid.
>
> yes. But I think, the worker should enter no-op, when walRcvState is
> WALRCV_STOPPED and not when walRcvState != WALRCV_STREAMING as it is
> okay to have WALRCV_WAITING/STARTING/RESTARTING. But the worker should
> exit no-op only when it finds walRcvState switched back to
> WALRCV_STREAMING.
>

Yeah, fully agree.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com