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
Andres Freund and...@2ndquadrant.com writes:
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.
On Sun, Jun 1, 2014 at 1:05 PM, Andres Freund and...@2ndquadrant.com
wrote:
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
Since a64ca63e59c11d8fe6db24eee3d82b61db7c2c83 pg_sleep() uses
WaitLatch() to wait. That's
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
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