Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS

Hi,

On Mon, Aug 2, 2021, at 11:08, Alvaro Herrera wrote:
> On 2021-Aug-02, Tom Lane wrote:
>
> > Robert Haas <robertmhaas(at)gmail(dot)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.

I think nearly all such cases are going to want some monitoring from within the database - which then needs shared memory.

And even if not - it's not really that useful to avoid a crash-restart if your worker dies with a segfault. There's no really legitimate reasons for completely unhandled errors even if not connected to shmem.

> 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.

It's not obstructing me right now. I noticed it'd crash on EXEC_BACKEND when I tried to understand some code (see the nearby thread about straightening out process startup).

I do think there's some potential gains in simplicity and robustness that are made mildly harder by a subprocess that first attaches and detaches from shm (it's the only case where we can't easily unify the place InitProcess() is called between EB and ! EB right now). There's several ways that could be tackled. Removing the need to have that if obviously one of them.

Regards,

Andres