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

On 06/09/2013 08:32 AM, MauMau wrote:
>
> - Failure of a disk containing data directory or tablespace
> If checkpoint can't write buffers to disk because of disk failure,
> checkpoint cannot complete, thus WAL files accumulate in pg_xlog/.
> This means that one disk failure will lead to postgres shutdown.
... which is why tablespaces aren't disposable, and why creating a
tablespace in a RAM disk is such an awful idea.

I'd rather like to be able to recover from this by treating the
tablespace as dead, so any attempt to get a lock on any table within it
fails with an error and already-in-WAL writes to it just get discarded.
It's the sort of thing that'd only be reasonable to do as a recovery
option (like zero_damaged_pages) since if applied by default it'd lead
to potentially severe and unexpected data loss.

I've seen a couple of people bitten by the misunderstanding that
tablespaces are a way to split up your data based on different
reliability requirements, and I really need to write a docs patch for
http://www.postgresql.org/docs/current/static/manage-ag-tablespaces.html
<http://www.postgresql.org/docs/9.2/static/manage-ag-tablespaces.html>
that adds a prominent warning like:

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.

(Opinions on the above?)

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services