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

- 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 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