Re: Redesigning checkpoint_segments

<div dir="ltr"><br /><div class="gmail_extra"><br /><br /><div class="gmail_quote">On Thu, Jun 6, 2013 at 10:00 AM,
JoshuaD. Drake <span dir="ltr"><<a href="mailto:jd@commandprompt.com"
target="_blank">jd@commandprompt.com</a>></span>wrote:<br /><blockquote class="gmail_quote" style="margin:0px 0px
0px0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br /> On 06/05/2013 05:37 PM, Robert
Haaswrote:<br /><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><br/> On Wed, Jun 5, 2013 at 3:24 PM, Fujii Masao <<a
href="mailto:masao.fujii@gmail.com"target="_blank">masao.fujii@gmail.com</a>> wrote:<br /><blockquote
class="gmail_quote"style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> OTOH, if
weuse max_wal_size as a hard limit, we can avoid such PANIC<br /> error and long down time. Of course, in this case,
oncemax_wal_size is<br /> reached, we cannot complete any query writing WAL until the checkpoint<br /> has completed
andremoved old WAL files. During that time, the database<br /> service looks like down from a client, but its down time
isshorter than the<br /> PANIC error case. So I'm thinking that some users might want the hard<br /> limit of pg_xlog
size.<br/></blockquote><br /> I wonder if we could tie this in with the recent proposal from the<br /> Heroku guys to
havea way to slow down WAL writing.  Maybe we have<br /> several limits:<br /></blockquote><br /></div> I didn't see
thatproposal, link? Because the idea of slowing down wal-writing sounds insane.<span class=""><font color="#888888"><br
/></font></span></blockquote>Hereit is:<br clear="all" /><a
href="http://www.postgresql.org/message-id/CAM3SWZQcyNxvPaskr-pxm8DeqH7_qevW7uqbhPCsg1FpSxKpoQ@mail.gmail.com">http://www.postgresql.org/message-id/CAM3SWZQcyNxvPaskr-pxm8DeqH7_qevW7uqbhPCsg1FpSxKpoQ@mail.gmail.com</a><br
/></div>--<br />Michael<br /></div></div>