Craig Ringer <craig@postnewspapers.com.au> 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
