Re: Support worker_spi to execute the function dynamically.

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Masahiro Ikeda <ikedamsh@oss.nttdata.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-07-28T04:45:29Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. worker_spi: Fix race condition in newly-added TAP tests

  2. worker_spi: Switch to TAP tests

  3. worker_spi: Use term "dynamic" for bgworkers launched with worker_spi_launch()

  4. Fix worker_spi when launching workers without shared_preload_libraries