On Thu, Jul 25, 2019 at 2:39 AM Merlin Moncure <mmonc...@gmail.com> wrote: > Server is generally running pretty well, and is high volume. This > query is not new and is also medium volume. Database rebooted in > about 4 seconds with no damage; fast enough we didn't even trip alarms > (I noticed this troubleshooting another issue). We are a couple of > bug fixes releases behind but I didn't see anything obvious in the > release notes suggesting a resolved issue. Anyone have any ideas? > thanks in advance.
> postgres: rms ysconfig 10.33.190.21(36788) > SELECT(ExecHashJoin+0x5a2)[0x5e2d32] Hi Merlin, Where's the binary from (exact package name, if installed with a package)? Not sure if this is going to help, but is there any chance you could disassemble that function so we can try to see what it's doing at that offset? For example on Debian if you have postgresql-9.6 and postgresql-9.6-dbg installed you could run "gdb /usr/lib/postgresql/9.6/bin/postgres" and then "disassemble ExecHashJoin". The code at "<+1442>" (0x5a2) is presumably calling free or some other libc thing (though I'm surprised not to see an intervening palloc thing). -- Thomas Munro https://enterprisedb.com
