RE: promotion related handling in pg_sync_replication_slots() - Mailing list pgsql-hackers

From Zhijie Hou (Fujitsu)
Subject RE: promotion related handling in pg_sync_replication_slots()
Date
Msg-id OS0PR01MB57166CFD699B571F173F431A94082@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: promotion related handling in pg_sync_replication_slots()  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: promotion related handling in pg_sync_replication_slots()
List pgsql-hackers
On Tuesday, April 16, 2024 2:52 PM Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote:


Hi,

> On Tue, Apr 16, 2024 at 10:00:04AM +0530, shveta malik wrote:
> > Please find v5 addressing above comments.
>
> Thanks!
>
> @@ -1634,9 +1677,14 @@ SyncReplicationSlots(WalReceiverConn *wrconn)  {
>         PG_ENSURE_ERROR_CLEANUP(slotsync_failure_callback,
> PointerGetDatum(wrconn));
>         {
> +               check_flags_and_set_sync_info(InvalidPid);
> +
>
> Given the fact that if the sync worker is running it won't be possible to trigger a
> manual sync with pg_sync_replication_slots(), what about also checking the
> "sync_replication_slots" value at the start of SyncReplicationSlots() and emmit
> an error if sync_replication_slots is set to on? (The message could explicitly
> states that it's not possible to use the function if sync_replication_slots is set to
> on).

I personally feel adding the additional check for sync_replication_slots may
not improve the situation here. Because the GUC sync_replication_slots can
change at any point, the GUC could be false when performing this addition check
and is set to true immediately after the check, so It could not simplify the logic
anyway.

Best Regards,
Hou zj



pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: promotion related handling in pg_sync_replication_slots()
Next
From: Daniel Gustafsson
Date:
Subject: Re: Add bump memory context type and use it for tuplesorts