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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
