On Wed, Jul 24, 2019 at 11:01 PM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Thu, Jul 25, 2019 at 2:39 AM Merlin Moncure <mmoncure@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
