klaus.mailinglists@xxxxxxxxx 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
