| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andreas Kretschmer <andreas(at)a-kretschmer(dot)de>, Shani Israeli <sisraeli(at)illusivenetworks(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: PANIC: could not write to log file {} at offset {}, length {}: Invalid argument |
| Date: | 2020-11-06 01:10:28 |
| Message-ID: | 20201106011028.GE21123@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, Nov 04, 2020 at 10:23:04PM -0500, Tom Lane wrote:
> The latter case would result in a LOG message "unrecognized win32 error
> code", so it would be good to know if any of those are showing up in
> the postmaster log.
Yeah. Not sure which one it could be here:
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-writefile
One possibility could also be ERROR_OPERATION_ABORTED, which is not in
the mapping table. So that would map to EINVAL.
> Seems like maybe it wasn't a great idea for _dosmaperr's fallback
> errno to be something that is also a real error code.
You could say that for any fallback errno as long as you don't know if
there's a LOG to show that a DWORD does not map with the table of
win32error.c, no?
(I got to wonder whether it would be worth the complexity to show more
information when using _dosmaperr() for WIN32 on stuff like
elog(ERROR, "%m"), just a wild thought).
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-11-06 01:19:51 | Re: PANIC: could not write to log file {} at offset {}, length {}: Invalid argument |
| Previous Message | Michael Paquier | 2020-11-06 00:38:32 | Re: PANIC: could not write to log file {} at offset {}, length {}: Invalid argument |