Re: pg_reload_conf() synchronously
От | Andres Freund |
---|---|
Тема | Re: pg_reload_conf() synchronously |
Дата | |
Msg-id | 20221105045108.wbz4eaaifgxosmlq@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pg_reload_conf() synchronously (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_reload_conf() synchronously
|
Список | pgsql-hackers |
Hi, On 2022-11-04 23:35:21 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Worth noting that this doesn't necessarily suffice to avoid race conditions in > > tests, if the test depends on *other* backends having seen the configuration > > changes. > > True, but do we have any such cases? I know I hit it twice and gave up on the tests. > > It might be worth to use the global barrier mechanism to count which backends > > have reloaded configuration and to provide a function / option to pg_sleep > > that waits for that. > > That ... seems like a lot of mechanism. And it could easily result > in undetected deadlocks, if any other session is blocked on you. > I seriously doubt that we should go there. Yea, it's not great. Probably ok enough for a test, but ... Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: