Re: WALWriter active during recovery

<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Thu, Dec 18, 2014 at 6:43 PM, Fujii
Masao<span dir="ltr"><<a href="mailto:masao.fujii@gmail.com" target="_blank">masao.fujii@gmail.com</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><spanclass="">On Tue, Dec 16, 2014 at 3:51 AM, Simon Riggs <<a
href="mailto:simon@2ndquadrant.com">simon@2ndquadrant.com</a>>wrote:<br /> > Currently, WALReceiver writes and
fsyncsdata it receives. Clearly,<br /> > while we are waiting for an fsync we aren't doing any other useful<br />
>work.<br /> ><br /> > Following patch starts WALWriter during recovery and makes it<br /> > responsible
forfsyncing data, allowing WALReceiver to progress other<br /> > useful actions.<br /><br /></span>+1<br /><span
class=""><br/> > At present this is a WIP patch, for code comments only. Don't bother<br /> > with anything other
thancode questions at this stage.<br /> ><br /> > Implementation questions are<br /> ><br /> > * How should
wewake WALReceiver, since it waits on a poll(). Should<br /> > we use SIGUSR1, which is already used for latch
waits,or another<br /> > signal?<br /><br /></span>Probably we need to change libpqwalreceiver so that it uses the
latch.<br/> This is useful even for the startup process to report the replay location to<br /> the walreceiver in real
time.<br/><span class=""><br /> > * Should we introduce some pacing delays if the WALreceiver gets too<br /> >
farahead of apply?<br /><br /></span>I don't think so for now. Instead, we can support synchronous_commit = replay,<br
/>and the users can use that new mode if they are worried about the delay of<br /> WAL replay.<br /><span class=""><br
/>> * Other questions you may have?<br /><br /></span>Who should wake the startup process so that it reads and
replaysthe WAL data?<br /> Current walreceiver. But if walwriter is responsible for fsyncing WAL data,<br /> probably
walwritershould do that. Because the startup process should not replay<br /> the WAL data which has not been fsync'd
yet.<br/></blockquote></div><br />Moved this patch to CF 2015-02 to not lose track of it and because it did not get any
reviews.<br/>-- <br /><div class="gmail_signature">Michael<br /></div></div></div>