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

From: Christoph Moench-Tegeder <cmt(at)burggraben(dot)net>
To: klaus(dot)mailinglists(at)pernau(dot)at
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: PANIC: could not flush dirty data: Cannot allocate memory
Date: 2022-11-15 21:17:05
Message-ID: Y3QB0aANtLBAjyVc@elch.exwg.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

## klaus(dot)mailinglists(at)pernau(dot)at (klaus(dot)mailinglists(at)pernau(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message gzh 2022-11-16 05:04:51 An I/O error occured while sending to the backend
Previous Message Thomas Munro 2022-11-15 20:55:17 Re: PANIC: could not flush dirty data: Cannot allocate memory