On Wed, Jul 24, 2019 at 11:01 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > > 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).
Thanks -- great suggestion. I'll report back with any interesting findings. merlin
