Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Date
Msg-id 202108021808.plo7fakfyd2o@alvherre.pgsql
Whole thread Raw
In response to Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  ("Andres Freund" <andres@anarazel.de>)
List pgsql-hackers
On 2021-Aug-02, Tom Lane wrote:

> Robert Haas <robertmhaas@gmail.com> writes:
> > If you're saying that this code has been 100% broken for 7 years and
> > nobody's noticed until now, then that suggests that nobody actually
> > uses non-shmem-connected bgworkers. I sort of hate to give up on that
> > concept but if we've really gone that many years without anyone
> > noticing obvious breakage then maybe we should.
> 
> Well, the problem only exists on Windows so maybe this indeed
> escaped notice.  Still, this is good evidence that the case isn't
> used *much*, and TBH I don't see many applications for it.
> I can't say I'm excited about putting effort into fixing it.

When I included this case I was thinking in tasks which would just run
stuff not directly connected to data.  Something like a sub-daemon: say
a connection pooler, which is a bgworker just so that it starts and
stops together with postmaster, and share facilities like GUC
configuration and SIGHUP handling, etc.  It doesn't look like anybody
has had an interest in developing such a thing, so if this is
obstructing your work, I don't object to removing the no-shmem case.

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: straightening out backend process startup
Next
From: "Bossart, Nathan"
Date:
Subject: Re: make MaxBackends available in _PG_init