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