Обсуждение: Experimenting with Postmaster variable scope

Hi,

While working on the postmaster latch stuff, one of the things I
looked into, but de-scoped for now, is how the postmaster code would
look if it didn't use global variables to track its sockets, children
and state (ie now that it's no longer necessary for technical
reasons).  Here's the quick experimental patch I came up with that
lifts most of the global variables out of postmaster.c and puts them
into a struct Postmaster, which is allocated in the postmaster and
freed in forked children.  Then 'pm' gets passed around to postmaster
subroutines and all references to X are replaced with pm->X (so
pm->ListenSockets, pm->WalWriterPid, pm->WalReceiverRequested, etc).

Unfortunately bgworker.c isn't quite so easy to refactor along these
lines, because its list of background workers, which you might think
should be in Postmaster private memory in the Postmaster struct much
like pm->BackendList, also needs to be accessible globally for
extensions to be able to register them in their init hook.  Perhaps
there should be separate 'running' and 'registered' worker lists.
That stopped me in my tracks (decisions are so much harder than
mechanical changes...), but I thought I'd share this concept patch
anyway...  This is not a proposal for 16, more of a sketch to see what
people's appetite is for global variable removal projects, which
(IMHO) increase clarity about module boundaries, but I guess also have
back-patching and code churn costs.