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
