Kelly Burkhart <kelly.burkhart@xxxxxxxxx> 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
