On Tue, Nov 15, 2022 at 10:54 AM Christoph Moench-Tegeder
<cmt@burggraben.net> wrote:
> ## klaus.mailinglists@pernau.at (klaus.mailinglists@pernau.at):
> > On several servers we see the error message: PANIC: could not flush
> > dirty data: Cannot allocate memory
> 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.
It must be sync_file_range(). The others are fallbacks that wouldn't
apply on a modern Linux.
It has been argued before that we might have been over-zealous
applying the PANIC promotion logic to sync_file_range(). It's used to
start asynchronous writeback to make the later fsync() call fast, so
it's "only a hint", but I have no idea if it could report a writeback
error from the kernel that would then be consumed and not reported to
the later fsync(), so I defaulted to assuming that it could.
