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)
