Looking at the latest streaming replication patch, I don't much like the
signaling between WAL sender and postmaster. It seems complicated, and
as a rule of thumb postmaster shouldn't be accessing shared memory. The
current signaling is:
1. A new connection arrives. A new backend process is forked forked like
for a normal connection.
2. When the new process is done with the initialization, it allocates
itself a slot from WalSndCtlData shared memory array. It marks its pid
there, sets registered = false, and signals postmaster with
PMSIGNAL_REGISTER_WALSENDER
3. Upon receiving that signal, postmaster scans the WalSndCtlData array
looking for entries with registered==false. For such entries, it scans
the postmaster-private backend list for a matching entry with the same
pid, marks the entry in the list as a walsender, and sets
registered=true in the shared memory entry.
This way postmaster knows which child processes are walsenders, when
it's time to signal them.
I think it would be better to utilize the existing array of child
processes in pmsignal.c. Instead of having postmaster peek into
WalSndCtlData, let's add a new state to PMChildFlags,
PM_CHILD_WALSENDER, which is just like PM_CHILD_ACTIVE but tells
postmaster that the child is not a normal backend but a walsender.
I've done that in my git branch.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
