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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
