On Tue, Nov 17, 2015 at 12:44 AM, Simon Riggs <si...@2ndquadrant.com> wrote:

> On 15 November 2015 at 10:41, Simon Riggs <si...@2ndquadrant.com> wrote:
>>  So anyway, consider me nudged to finish my patch to provide capability
>> for that by 1 Jan.
> My earlier patch aimed to allow WALReceiver to wait on both a latch and a
> socket as well as allow WALWriter to be active, so that WALReceiver could
> reply more quickly and handle greater workload. As I explained previously
> when we discussed that in recent posts, it is necessary infrastructure to
> have anybody wait on anything higher than remote-fsync. I aim to complete
> that by 1 Jan.

Right, handing write/fsync work off to WALWriter in standbys makes a lot of
sense for any kind of writer-waits system, so that WALReceiver doesn't
spend time in long syscalls which wouldn't play nicely with signals
(whether from 'kill' or SetLatch) and can deal with network IO with the
lowest possible latency.  I would like to help test/review that, if that
could be useful.

The SIGUSR1 code in the WalReceiverMain and WalRecvWakeup in this patch
works well enough for now for proof-of-concept purposes until then.

Thomas Munro

Reply via email to