Re: Hard limit on WAL space used (because PANIC sucks)

<div class="moz-cite-prefix">On 06/09/2013 08:32 AM, MauMau wrote:<br /></div><blockquote
cite="mid:D117F8165E894FA1B805302504C6F1D7@maumau"type="cite"><br /> - Failure of a disk containing data directory or
tablespace<br /> If checkpoint can't write buffers to disk because of disk failure, checkpoint cannot complete, thus
WALfiles accumulate in pg_xlog/. <br /> This means that one disk failure will lead to postgres shutdown. <br
/></blockquote>... which is why tablespaces aren't disposable, and why creating a tablespace in a RAM disk is such an
awfulidea.<br /><br /> I'd rather like to be able to recover from this by treating the tablespace as dead, so any
attemptto get a lock on any table within it fails with an error and already-in-WAL writes to it just get discarded.
It'sthe sort of thing that'd only be reasonable to do as a recovery option (like zero_damaged_pages) since if applied
bydefault it'd lead to potentially severe and unexpected data loss.<br /><br /> I've seen a couple of people bitten by
themisunderstanding that tablespaces are a way to split up your data based on different reliability requirements, and I
reallyneed to write a docs patch for <a
href="http://www.postgresql.org/docs/9.2/static/manage-ag-tablespaces.html">http://www.postgresql.org/docs/current/static/manage-ag-tablespaces.html</a>
thatadds a prominent warning like:<br /><br /> WARNING: Every tablespace must be present before the database can be
started.There is no easy way to recover the database if a tablespace is lost to disk failure, deletion, use of volatile
storage,etc. <b>Do not put a tablespace on a RAM disk</b>; instead just use UNLOGGED tables.<br /><br />
(Opinionson the above?)<br /><br /><pre class="moz-signature" cols="72">-- Craig Ringer                   <a
class="moz-txt-link-freetext"href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a>PostgreSQL Development,
24x7Support, Training & Services</pre>