| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| 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:19:51 |
| Message-ID: | 1533856.1604625591@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> (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).
Maybe. It's been in the back of my mind for a long time that the
_dosmaperr() mapping may be confusing us in some of these hard-to-explain
trouble reports. It'd be great if we could see the original Windows error
code too. Not quite sure how to mechanize that, though. Places where we
do stuff like save-and-restore errno across some other operation would break
any easy solution.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Treat | 2020-11-06 02:50:57 | Re: Christopher Browne |
| Previous Message | Michael Paquier | 2020-11-06 01:10:28 | Re: PANIC: could not write to log file {} at offset {}, length {}: Invalid argument |