Re: 035_standby_logical_decoding unbounded hang
От | Noah Misch |
---|---|
Тема | Re: 035_standby_logical_decoding unbounded hang |
Дата | |
Msg-id | 20240219230930.d9@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: 035_standby_logical_decoding unbounded hang (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: 035_standby_logical_decoding unbounded hang
|
Список | pgsql-hackers |
On Fri, Feb 16, 2024 at 06:37:38AM +0000, Bertrand Drouvot wrote: > On Thu, Feb 15, 2024 at 12:48:16PM -0800, Noah Misch wrote: > > On Wed, Feb 14, 2024 at 03:31:16PM +0000, Bertrand Drouvot wrote: > > > What about creating a sub, say wait_for_restart_lsn_calculation() in Cluster.pm > > > and then make use of it in create_logical_slot_on_standby() and above? (something > > > like wait_for_restart_lsn_calculation-v1.patch attached). > > > > Waiting for restart_lsn is just a prerequisite for calling > > pg_log_standby_snapshot(), so I wouldn't separate those two. > > Yeah, makes sense. > > > If we're > > extracting a sub, I would move the pg_log_standby_snapshot() call into the sub > > and make the API like one of these: > > > > $standby->wait_for_subscription_starting_point($primary, $slot_name); > > $primary->log_standby_snapshot($standby, $slot_name); > > > > Would you like to finish the patch in such a way? > > Sure, please find attached standby-slot-test-2-race-v2.patch doing so. I used > log_standby_snapshot() as it seems more generic to me. Thanks. Pushed at commit 0e16281.
В списке pgsql-hackers по дате отправления: