Re: fix bgworkers in EXEC_BACKEND

On 2012-12-27 20:06:07 +0200, Heikki Linnakangas wrote:
> On 27.12.2012 19:15, Alvaro Herrera wrote:
> >I committed background workers three weeks ago, claiming it worked on
> >EXEC_BACKEND, and shortly thereafter I discovered that it didn't. I
> >noticed that the problem is the kludge to cause postmaster and children
> >to recompute MaxBackends after shared_preload_libraries is processed; so
> >the minimal fix is to duplicate this bit, from PostmasterMain() into
> >SubPostmasterMain():
>
> If I'm reading the code correctly, GetNumShmemAttachedBgWorkers() works by
> walking through a backend-local list. What happens if a background worker
> fails to register itself when preloaded in one backend? That backend would
> calculate a different value of MaxBackends, with interesting consequences.
> That would be a clear case of "don't do that", but nevertheless, I think it
> would be better if we didn't rely on that. I'd suggest adding MaxBackends to
> the list of variables passed from postmaster to backends via
> BackendParameters.

I am still worried about the following scenario in the EXEC_BACKEND case:

1) postmaster starts
2) reads config
3) executes _PG_init for shared_preload_libraries
4) library 'abc' gets config value 'abc.num_workers = 2' and registers as many workers
5) some time goes by, workers, backends start
6) abc.num_workers gets changed to 3, SIGHUP
7) some worker dies and gets restarted
8) _PG_init in the new worker does one more RegisterBackgroundWorker than before
9) ???

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services