Kelly Burkhart <kelly.burkhart@gmail.com> writes:
> Hello, I've had two core dumps in the last couple of weeks. The most
> recent, yesterday was on version 10.2:
> (gdb) bt
> #0 0x00007f317a043886 in get_next_seq () from /lib64/libc.so.6
> #1 0x00007f317a044acc in strcoll_l () from /lib64/libc.so.6
> #2 0x00000000007ced5f in varstrfastcmp_locale ()
> #3 0x000000000081b6fb in qsort_ssup ()
> #4 0x000000000081d8e1 in tuplesort_performsort ()
Hm. If you'd just showed this one, my thoughts might bend towards a bug
in our sort abbreviation logic, which is relatively new ...
> (gdb) bt
> #0 0x00007f6e1f09d8ea in get_next_seq () from /lib64/libc.so.6
> #1 0x00007f6e1f09eacc in strcoll_l () from /lib64/libc.so.6
> #2 0x00000000007cf70b in varstr_cmp ()
> #3 0x000000000075f25b in compareJsonbContainers ()
> #4 0x000000000075d8f2 in jsonb_eq ()
... but this stack trace is not going anywhere near that code. The
common factor is just strcoll_l(), raising the possibility that you're
dealing with a glibc bug, or perhaps corrupted locale data on your
machine. Are you up-to-date on glibc patches?
regards, tom lane
