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-14 21:54:03 |
Message-ID: | Y3K4+z5fP9mNElMj@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):
> On several servers we see the error message: PANIC: could not flush
> dirty data: Cannot allocate memory
As far as I can see, that "could not flush dirty data" happens total
three times in the code - there are other places where postgresql could
PANIC on fsync()-and-stuff-related issues, but they have different
messages.
Of these three places, there's an sync_file_range(), an posix_fadvise()
and an msync(), all in src/backend/storage/file/fd.c. "Cannot allocate
memory" would be ENOMEM, which posix_fadvise() does not return (as per
it's docs). So this would be sync_file_range(), which could run out
of memory (as per the manual) or msync() where ENOMEM actually means
"The indicated memory (or part of it) was not mapped". Both cases are
somewhat WTF for this setup.
What filesystem are you running?
Regards,
Christoph
--
Spare Space
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2022-11-14 23:57:08 | Re: Support logical replication of DDLs |
Previous Message | Tom Lane | 2022-11-14 21:29:58 | Re: PANIC: could not flush dirty data: Cannot allocate memory |