On Fri, Jul 28, 2023 at 12:06:33PM +0200, Alvaro Herrera wrote:
> Hmm, I think having all the workers doing their in the same table is
> better -- if nothing else, because it gives us the opportunity to show
> how to use some other coding technique (but also because we are forced
> to write the SQL code in a way that's correct for potentially multiple
> concurrent workers, which sounds useful to demonstrate). Can't we
> instead solve the race condition by having some shared resource that
> blocks the other workers from proceeding until the schema has been
> created? Perhaps an LWLock, or a condition variable, or an advisory
> lock.
That's an idea interesting idea that you have here. So basically, you
would have all the workers use the same schema do their counting work
for the same base table? Or should each worker use the same schema,
perhaps defined by a GUC, but different tables? One thing that has
been itching me a bit with this module was to be able to pass down to
the main worker routine more arguments than just an int ID, but I
could not find myself do that for just for the wait event patch, like:
- The database to connect to.
- The table to create.
- The schema to use.
If any of these are NULL, just use as default what we have now, with
perhaps the bgworker PID as ID instead of a user-specified one.
Having a shared memory state is second thing I was planning to add,
and that can be useful as point of reference in a template. The other
patch about custom wait events introduces that, FWIW, to track the
custom wait events added.
--
Michael
