PG Bug reporting form <noreply@postgresql.org> writes:
> PostgreSQL version: 10.5
> Operating system: Debian stretch 9.11. Core version: 4.9.0-11-amd64
> Core was generated by `postgres: apipy pgapp 10.10.24.20(370'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x00007fb9b5d7a303 in epoll_wait () at
> ../sysdeps/unix/syscall-template.S:84
> 84 ../sysdeps/unix/syscall-template.S: No such file or directory.
> (gdb) bt
> #0 0x00007fb9b5d7a303 in epoll_wait () at
> ../sysdeps/unix/syscall-template.S:84
> #1 0x000056501737c618 in WaitEventSetWait ()
> #2 0x00005650172a6687 in secure_read ()
> #3 0x00005650172b0310 in ?? ()
> #4 0x00005650172b1155 in pq_getbyte ()
> #5 0x000056501739d537 in PostgresMain ()
> #6 0x00005650170fc9b5 in ?? ()
> #7 0x0000565017333d1c in PostmasterMain ()
> #8 0x00005650170fdda1 in main ()
That's a mighty interesting backtrace; I don't recall having seen any
reports of crashes in epoll_wait() before. (Well, there's [1],
but I have my doubts about whether that reported backtrace can be
trusted at all.)
The thing is that it's hard to see how a crash in epoll_wait() would
be our bug and not glibc's. Maybe a wild value of the events pointer
could cause that rather than the expected EFAULT result, but it's
fairly clear from the WaitEventSet code that it can't pass a wild
pointer. nevents has to be constant 1, too, given this stack trace.
So I'm suspecting an OS bug. The fact that you're running an EOL'd
Debian branch doesn't inspire much confidence that that's impossible.
I suggest an OS update. While you're at it, update Postgres too ---
10.5 is nine quarterly releases out of date.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/16094-8fb7061e5370fb00%40postgresql.org