On Wed, Aug 5, 2015 at 3:33 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > This idea looks good.
Thanks. It needs testing though to see if it really works as intended. Can you look into that? > Looking at larger picture, we should also enable this feature to be used by > auxilliary processes. It's very hard to add a new auxilliary process in > current code. One has to go add code at many places to make sure that the > auxilliary processes die and are re-started correctly. Even tougher to add a > parent auxilliary process, which spawns multiple worker processes.That would > be whole lot simpler if we could allow the auxilliary processes to use > background worker infrastructure (which is what they are utlimately). That's a separate patch, but, sure, we could do that. I agree with Alvaro's comments: the postmaster should start all children. Other processes should just request that it do so. We have two mechanisms for that right now: the one used by bgworkers, and the one used by the AV launcher. > BGWORKER_SHMEM_ACCESS has similar usage, except that it resets the on exit > callbacks and detaches the shared memory segment from the background worker. > That avoids a full cluster restart when one of those worker which can not > corrupt shared memory dies. But I do not see any check to prevent such > backend from calling PGSharedMemoryReattach() There isn't, but you shouldn't do that. :-) This is C code; you can't protect against actively malicious code. > So it looks like, it suffices to assume that background worker either needs > to access shared memory or doesn't. Any background worker having shared > memory access can also access database and thus becomes part of the backend > list. Or may be we just avoid these flags and treat every background worker > as if it passed both these flags. That will simplify a lot of code. I think it's useful to support workers that don't have shared memory access at all, because those can crash without causing a system-wide reset. But I don't see the point in distinguishing between workers with shared-memory access and those with a database connection. I mean, obviously the worker needs to be able to initialize itself either way, but there seems to be no reason to force that to be signalled in bgw_flags. It can just depend on whether BackgroundWorkerInitializeConnection gets called. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
