On Fri, 2011-01-14 at 14:08 +0200, Heikki Linnakangas wrote:
> On 14.01.2011 14:01, Simon Riggs wrote:
> > On Fri, 2011-01-14 at 13:47 +0200, Heikki Linnakangas wrote:
> >> On 14.01.2011 13:15, Simon Riggs wrote:
> >>> /*
> >>> + * Recheck shared recoveryPause by polling.
> >>> + *
> >>> + * XXX It might seem we should do this via a shared Latch, but
> >>> + * currently we only support one shared latch per process and
> >>> + * that is already taken for Startup process. Polling is used
> >>> + * in other places in xlog.c already, so not a concern.
> >>> + */
> >>
> >> There is no such limitation with latches.
> >
> > SIGUSR1 handler can only handle one shared latch
>
> You can only *wait* for one latch at a time, but you can own more than
> that. AFAICS you would never need to wait for the recovery-pause-latch
> at the same time as the other latch.
Yes, I understand.
Trouble is, if you wait on Latch X and other processes send wakeup
assuming you were waiting on Latch Y, then this will erroneously wake
you up.
So a process can have more than one shared latch, BUT other processes
don't know and can't tell which latch you're waiting on. Yes, you can
get around that, but not via the direct support of the latch module, as
currently written.
Polling is fine in that case, and we already do elsewhere, so it wasn't
critical for me to extend latch support to implement this.
> (That you can't wait for more than one latch at a time isn't a
> limitation of the SIGUSR1 handler either. The signal handler and the
> self-pipe mechanism wouldn't need any changes to support multi-latch
> waits. We're just missing a WaitMultipleLatches() function that would
> check the is_set flag on multiple latches.)
Something for the future.
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
