Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS

On 2021-Aug-02, Andres Freund wrote:

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

True. Observability for such things is critical (pgbouncer goes quite
some trouble to offer SQL-queryable views into its metrics), which kills
the argument.

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

Hmm, I don't remember that an shmem-unconnected bgworker first connected
to it and then let go. It seems weird to do it that way. My intention,
as far as I recall, is that they would just never connect to shmem,
period.

--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)