Re: PANIC: could not flush dirty data: Cannot allocate memory - Mailing list pgsql-general

From Christoph Moench-Tegeder
Subject Re: PANIC: could not flush dirty data: Cannot allocate memory
Date
Msg-id Y3QB0aANtLBAjyVc@elch.exwg.net
Whole thread Raw
In response to Re: PANIC: could not flush dirty data: Cannot allocate memory  (klaus.mailinglists@pernau.at)
List pgsql-general
## klaus.mailinglists@pernau.at (klaus.mailinglists@pernau.at):

> AFAIU the problem is not related to the memory settings in 
> postgresql.conf. It is the kernel that
> for whatever reasons report ENOMEM. Correct?

Correct, there's a ENOMEM from the kernel when writing out data.

> Filesystem is ext4. VM technology is mixed: VMware, KVM and XEN PV. 
> Kernel is 5.15.0-52-generic.

I do not suspect the filesystem per se, ext4 is quite common and we
would have heard something about that (but then, someone gotta be
the first reporter?). I would believe that the kernel would raise
a bunch of printks if it hit ENOMEM in the commonly used paths, so
you would see something in dmesg or wherever you collect your kernel
log if it happened where it was expected.
And coming from the other side: does this happen on all the hosts,
or is it limited to one host or one technology? Any uncommon options
on the filesystem or the mount point? Anything which could mess
with your block devices? (I'm expecially thinking "antivirus" because
it's always "0 days since the AV ate a database" and they tend to
raise errors in the weirdest places, which would fit the bill here;
but anythig which is not "commonly in use everywhere" could be a
candidate).

Regards,
Christoph

-- 
Spare Space



pgsql-general by date:

Previous
From: Thomas Munro
Date:
Subject: Re: PANIC: could not flush dirty data: Cannot allocate memory
Next
From: gzh
Date:
Subject: An I/O error occured while sending to the backend