Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> writes: > These reports seem to come up a bit, with disk full issues resulting in > the need to pg_resetxlog, dump, and re-initdb, but I wouldn't be too > shocked if they all turned out to be on xfs or something like that. Well, there are cases where that might actually be the best strategy, but PG by itself will not lose data on a disk-full condition. What it will do is shut down and refuse to play until you find it some more disk space. If you have no way to clear some space on the partition ... Also, over the years we have found various bugs that contributed to bad behavior in extreme circumstances. For instance 7.x had a problem that a very long index build prevented checkpoints from completing, which would cause pg_xlog to bloat because WAL segments couldn't be recycled: http://archives.postgresql.org//pgsql-general/2004-05/msg00414.php which led to cases like this one: http://archives.postgresql.org//pgsql-general/2005-03/msg01373.php I think I actually recommended pg_resetxlog in that case because the alternative was to wait for it to churn through 100GB of uncheckpointed WAL. Another interesting example is here: http://archives.postgresql.org//pgsql-hackers/2004-01/msg00530.php explanation here: http://archives.postgresql.org/pgsql-hackers/2004-01/msg00606.php in which Postgres survived an out-of-space condition for quite some time without data loss. It did finally panic because of a rather minor bug in the pg_clog logic ... but still did not lose any committed transactions. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
