<br /><br /><div class="gmail_quote">On Sat, Nov 1, 2008 at 10:02 PM, Simon Riggs <span dir="ltr"><<a
href="mailto:simon@2ndquadrant.com">simon@2ndquadrant.com</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hot Standby patch,
includingall major planned features.<br /><br /></blockquote></div><br />While experimenting with the patch, I noticed
thatsometimes the archiver process indefinitely waits for WALInsertLock. I haven't spent much time debugging that, but
thefollowing chunk clearly seems to be buggy. The WALInsertLock is not released if (leavingArchiveRecovery == true).<br
/><br/>--- 6565,6592 ----<br /> }<br /> }<br /><br />! if (leavingArchiveRecovery)<br />!
checkPoint.redo= GetRedoLocationForArchiveCheckpoint();<br />! else<br /> {<br />! /*<br />! *
Computenew REDO record ptr = location of next XLOG record.<br /> ! *<br />! * NB: this is NOT necessarily
wherethe checkpoint record itself will be,<br />! * since other backends may insert more XLOG records while
we'reoff doing<br />! * the buffer flush work. Those XLOG records are logically after the<br /> ! *
checkpoint,even though physically before it. Got that?<br />! */<br />! checkPoint.redo =
GetRedoLocationForCheckpoint();<br/><br />! /*<br />! * Now we can release WAL insert lock, allowing other
xactsto proceed<br /> ! * while we are flushing disk buffers.<br />! */<br />!
LWLockRelease(WALInsertLock);<br/> }<br /><br /> /*<br /> * If enabled, log checkpoint start. We postpone
thisuntil now so as not<br /> * to log anything if we decided to skip the checkpoint.<br /> */<br /><br /><br
/>Thanks,<br/>Pavan<br clear="all" /><br />-- <br />Pavan Deolasee<br />EnterpriseDB <a
href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br/>