Re: Support worker_spi to execute the function dynamically.
От | Michael Paquier |
---|---|
Тема | Re: Support worker_spi to execute the function dynamically. |
Дата | |
Msg-id | ZMNH6Q+W3lhMGXoh@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Support worker_spi to execute the function dynamically. (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Support worker_spi to execute the function dynamically.
Re: Support worker_spi to execute the function dynamically. Re: Support worker_spi to execute the function dynamically. |
Список | pgsql-hackers |
On Thu, Jul 27, 2023 at 07:23:32PM -0700, Andres Freund wrote: > As written, dynamic and static workers race each other. It doesn't make a lot > of sense to me to use the same ids for either? > > The attached patch reproduces the problem on master. > > Note that without the sleep(3) in the test the workers don't actually finish > starting, the test shuts down the cluster before that happens... So you have faced a race condition where the commit of the transaction doing the schema creation for the static workers is delayed long enough that the dynamic workers don't see it, and bumped on a catalog conflict when they try to create the same schemas. Having each bgworker on its own schema would be enough to prevent conflicts, but I'd like to add a second thing: a check on pg_stat_activity.wait_event after starting the workers. I have added something like that in the patch I have posted today for the custom wait events at [1] and it enforces the startup sequences of the workers in a stricter way. Does the attached take care of your issue? [1]: https://www.postgresql.org/message-id/ZMMUiR7kvzPWenhF@paquier.xyz -- Michael
Вложения
В списке pgsql-hackers по дате отправления: