On 2014-10-30 15:27:13 +0200, Heikki Linnakangas wrote:
> The comment on PGPROC.procLatch in storage/proc.h says just this:
>
> > Latch procLatch; /* generic latch for process */
>
> This needs a lot more explaining. It's now used by signal handlers to
> interrupt a read or write to the socket; that should be mentioned. What else
> is it used for? (for waking up a backend in synchronous replication, at
> least) What are the rules on when to arm it and when to reset it?
Hm. I agree it use expaned commentary, but I'm unsure if that much
detail is really warranted. Any such documentation seems to be almost
guaranteed to be out of date. As evidenced that there's none to date...
> Would it be more clear to use a separate, backend-private, latch, for the
> signals? I guess that won't work, though, because sometimes we need need to
> wait for a wakeup from a different process or from a signal at the same time
> (SyncRepWaitForLSN() in particular). Not without adding a variant of
> WaitLatch that can wait on two latches simultaneously, anyway.
I wondered the same, but I don't really see what it'd buy us during
normal running. It seems like it'd just make code more complex without
leading to relevantly fewer wakeups.
> The assumption in secure_raw_read that MyProc exists is pretty surprising. I
> understand why it's that way, and there's a comment in PostgresMain
> explaining why the socket cannot be put into non-blocking mode earlier, but
> it's still a bit whacky. Not sure what to do about that.
It makes me quite unhappy too. I looked what it'd take to make proclatch
available earlier, but it wasn't pretty. I wondered whether we could use
a 'early proc latch' in MyProcLatch that used until we're fully attached
to shared memory. Then, when attaching to shared memory we'd set the old
latch once, and reset MyProcLatch to the shared memory one.
But that's pretty ugly.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services