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

On Fri, Jan 12, 2024 at 5:50 PM shveta malik <shveta.malik@gmail.com> wrote:
>
> There are multiple approaches discussed and tried when it comes to
> starting a slot-sync worker. I am summarizing all here:
>
>  1) Make slotsync worker as an Auxiliary Process (like checkpointer,
> walwriter, walreceiver etc). The benefit this approach provides is, it
> can control begin and stop in a more flexible way as each auxiliary
> process could have different checks before starting and can have
> different stop conditions. But it needs code duplication for process
> management(start, stop, crash handling, signals etc) and currently it
> does not support db-connection smoothly (none of the auxiliary process
> has one so far)
>

As slotsync worker needs to perform transactions and access syscache,
we can't make it an auxiliary process as that doesn't initialize the
required stuff like syscache. Also, see the comment "Auxiliary
processes don't run transactions ..." in AuxiliaryProcessMain() which
means this is not an option.

>
> 2) Make slotsync worker as a 'special' process like AutoVacLauncher
> which is neither an Auxiliary process nor a bgworker one. It allows
> db-connection and also provides flexibility to have start and stop
> conditions for a process.
>

Yeah, due to these reasons, I think this option is worth considering
and another plus point is that this allows us to make enable_syncslot
a PGC_SIGHUP GUC rather than a PGC_POSTMASTER.

>
> 3) Make slotysnc worker a bgworker. Here we just need to register our
> process as a bgworker (RegisterBackgroundWorker()) by providing a
> relevant start_time and restart_time and then the process management
> is well taken care of. It does not need any code-duplication and
> allows db-connection smoothly in registered process. The only thing it
> lacks is that it does not provide flexibility of having
> start-condition which then makes us to have 'enable_syncslot' as
> PGC_POSTMASTER parameter rather than PGC_SIGHUP. Having said this, I
> feel enable_syncslot is something which will not be changed frequently
> and with the benefits provided by bgworker infra, it seems a
> reasonably good option to choose this approach.
>

I agree but it may be better to make it a PGC_SIGHUP parameter.

> 4) Another option is to have Logical Replication Launcher(or a new
> process) to launch slot-sync worker. But going by the current design
> where we have only 1 slotsync worker, it may be an overhead to have an
> additional manager process maintained.
>

I don't see any good reason to have an additional launcher process here.

>
> Thus weighing pros and cons of all these options, we have currently
> implemented the bgworker approach (approach 3).  Any feedback is
> welcome.
>

I vote to go for (2) unless we face difficulties in doing so but (3)
is also okay especially if others also think so.

--
With Regards,
Amit Kapila.