On 2014-05-30 10:30:42 +0530, Amit Kapila wrote:
> On Wed, May 28, 2014 at 8:53 PM, Andres Freund <and...@2ndquadrant.com>
> wrote:
> > Hi,
> >
> > Since a64ca63e59c11d8fe6db24eee3d82b61db7c2c83 pg_sleep() uses
> > WaitLatch() to wait. That's fine in itself. But
> > procsignal_sigusr1_handler, which is used e.g. when resolving recovery
> > conflicts, doesn't unconditionally do a SetLatch().
> > That means that we'll we'll currently not be able to cancel conflicting
> > backends during recovery for 10min. Now, I don't think that'll happen
> > too often in practice, but it's still annoying.
> How will such a situation occur, aren't we using pg_usleep during
> RecoveryConflict functions
> (ex. in ResolveRecoveryConflictWithVirtualXIDs)?

I am not sure what you mean. pg_sleep() is the SQL callable function, a
different thing to pg_usleep(). The latter isn't interruptible on all
platforms, but the sleep times should be short enough for that not to
I am pretty sure by now that the sane fix for this is to add a
SetLatch() call to RecoveryConflictInterrupt(). All the signal handlers
that deal with query cancelation et al. do so, so it seems right that
RecoveryConflictInterrupt() does so as well.


Andres Freund

 Andres Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to