On Sun, Jul 17, 2011 at 8:20 PM, Peter Geoghegan <pe...@2ndquadrant.com> wrote: > This is a bit of a detour, but probably a useful one. Attached is a > patch that replaces a tight PostmasterIsAlive() polling loop in the AV > launcher with a latch, making use of the new WL_POSTMASTER_DEATH > functionality. It's similar to what we've already done for the > archiver. It is relatively straightforward as these auxiliary process > polling loop elimination patches go (certainly compared to what we're > contemplating with the WAL writer), but it raises some questions that > we were lucky to have been able to avoid when I worked on the > archiver. Obviously, this patch isn't finished.
Might be good to start a new thread for each auxilliary process, or we may get confused. > We register various generic signal handlers for the AVLauncher, > including StatementCancelHandler(). Of course, signals that are > handled generically have the same potential to invalidate WaitLatch() > timeout as any other type of signal. We should be mindful of this. Right. > ISTM that these generic handlers ought to be handling this > generically, and that there should be a Latch for just this purpose > for each process within PGPROC. We already have this Latch in PGPROC: > > Latch waitLatch; /* allow us to wait for sync rep */ > > Maybe its purpose should be expanded to "current process Latch"? I think that could be a really good idea, though I haven't looked at it closely enough to be sure. > Another concern is, what happens when we receive a signal, generically > handled or otherwise, and have to SetLatch() to avoid time-out > invalidation? Should we just live with a spurious > AutoVacLauncherMain() iteration, or should we do something like check > if the return value of WaitLatch indicates that we woke up due to a > SetLatch() call, which must have been within a singal handler, and > that we should therefore goto just before WaitLatch() and elide the > spurious iteration? Given that we can expect some signals to occur > relatively frequently, spurious iterations could be a real concern. Really? I suspect that it doesn't much matter exactly how many machine language instructions we execute on each wake-up, within reasonable bounds, of course. Maybe some testing is in order? On another note, I might be inclined to write something like: if ((return_value_of_waitlatch & WL_POSTMASTER_DEATH) && !PostmasterIsAlive()) proc_exit(1); ...so as to avoid calling that function unnecessarily on every iteration. > Incidentally, should I worry about the timeout long for WaitLatch() > overflowing? How would that happen? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
