| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Christoph Moench-Tegeder <cmt(at)burggraben(dot)net>, klaus(dot)mailinglists(at)pernau(dot)at, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: PANIC: could not flush dirty data: Cannot allocate memory |
| Date: | 2022-11-15 04:05:23 |
| Message-ID: | 1004346.1668485123@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> 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.
Certainly, if it reports EIO, we should panic. But maybe not for
ENOMEM? One would assume that that means that the request didn't
get queued for lack of in-kernel memory space ... in which case
"nothing happened".
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | klaus.mailinglists | 2022-11-15 12:23:56 | Re: PANIC: could not flush dirty data: Cannot allocate memory |
| Previous Message | Kyotaro Horiguchi | 2022-11-15 03:05:33 | Re: How to check stream replication latest history status |