Re: promotion related handling in pg_sync_replication_slots()
От | Bertrand Drouvot |
---|---|
Тема | Re: promotion related handling in pg_sync_replication_slots() |
Дата | |
Msg-id | Zh5DPsa38T0NnJEe@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
Ответ на | Re: promotion related handling in pg_sync_replication_slots() (shveta malik <shveta.malik@gmail.com>) |
Ответы |
Re: promotion related handling in pg_sync_replication_slots()
|
Список | pgsql-hackers |
Hi, On Tue, Apr 16, 2024 at 02:06:45PM +0530, shveta malik wrote: > On Tue, Apr 16, 2024 at 1:55 PM Zhijie Hou (Fujitsu) > <houzj.fnst@fujitsu.com> wrote: > > 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. > > +1. > I feel doc and "cannot synchronize replication slots concurrently" > check should suffice. > > In the scenario which Hou-San pointed out, if after performing the > GUC check in SQL function, this GUC is enabled immediately and say > worker is started sooner than the function could get chance to sync, > in that case as well, SQL function will ultimately get error "cannot > synchronize replication slots concurrently", even though GUC is > enabled. Thus, I feel we should stick with samer error in all > scenarios. Okay, fine by me, let's forget about checking sync_replication_slots then. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: