Re: PANIC: could not flush dirty data: Cannot allocate memory

klaus.mailinglists@pernau.at writes:
> On several servers we see the error message: PANIC:  could not flush 
> dirty data: Cannot allocate memory

What that's telling you is that fsync (or some equivalent OS call)
returned ENOMEM, which would seem to be a kernel-level deficiency.
Perhaps you could dodge it by using a different wal_sync_method setting,
but complaining to your kernel vendor seems like the main thing
to be doing.

The reason we treat it as a PANIC condition is

 * Failure to fsync any data file is cause for immediate panic, unless
 * data_sync_retry is enabled.  Data may have been written to the operating
 * system and removed from our buffer pool already, and if we are running on
 * an operating system that forgets dirty data on write-back failure, there
 * may be only one copy of the data remaining: in the WAL.  A later attempt to
 * fsync again might falsely report success.  Therefore we must not allow any
 * further checkpoints to be attempted.  data_sync_retry can in theory be
 * enabled on systems known not to drop dirty buffered data on write-back
 * failure (with the likely outcome that checkpoints will continue to fail
 * until the underlying problem is fixed).

As noted here, turning on data_sync_retry would reduce the PANIC to
a WARNING.  But I wouldn't recommend that without some assurances
from your kernel vendor about what happens in the kernel after such a
failure.  The panic restart should (in theory) ensure data consistency
is preserved; without it we can't offer any guarantees.

            regards, tom lane