Re: BUG #13490: Segmentation fault on pg_stat_activity

Here's the session with debug_query_string:

ubuntu@hostname:~=E2=9F=AB sudo gdb -q -c /var/lib/postgresql/9.5/main/core
/usr/lib/postgresql/9.5/bin/postgres
Reading symbols from /usr/lib/postgresql/9.5/bin/postgres...Reading symbols
from
/usr/lib/debug/.build-id/7b/273fca376bfad4ea4bb0c4d3099d62ecc9c124.debug...=
done.
done.
[New LWP 16028]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: postgres database 127.0.0.1(42063) BIND
                          '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  get_tle_by_resno (tlist=3D0x7fd0d5da27c0, resno=3Dresno@entry=3D6) at
/tmp/buildd/postgresql-9.5-9.5~alpha1/build/../src/backend/parser/parse_rel=
ation.c:2832
2832
 /tmp/buildd/postgresql-9.5-9.5~alpha1/build/../src/backend/parser/parse_re=
lation.c:
No such file or directory.
(gdb) printf "%s\n", debug_query_string
SELECT application_name AS source, client_addr AS ip, COUNT(*) AS
total_connections FROM pg_stat_activity WHERE pid <> pg_backend_pid() GROUP
BY application_name, ip ORDER BY COUNT(*) DESC, application_name ASC,
client_addr ASC
(gdb)


Thanks,
Michael J. Bommarito II, CEO
Bommarito Consulting, LLC
*Web:* http://www.bommaritollc.com
*Mobile:* +1 (646) 450-3387

On Sat, Jul 11, 2015 at 6:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Michael Bommarito <michael@bommaritollc.com> writes:
> > Hello Michael,
> >   Here is the offending query and gdb session/stacktrace output.  Pleas=
e
> > let me know if we can provide anything else from gdb or logs that can b=
e
> > anonymized.
>
> > *Query:*
> > 2015-07-11 12:57:41 UTC [12803-7] LOG:  server process (PID 20696) was
> > terminated by signal 11: Segmentation fault
> > 2015-07-11 12:57:41 UTC [12803-8] DETAIL:  Failed process was running:
> > SELECT COUNT(*) FROM pg_stat_activity WHERE pid <> pg_backend_pid()
>
> I tried tracing through the logic using the line numbers shown in this
> stack trace, and soon decided that they didn't seem to match the query
> you show above --- but on closer look, that's to be expected, because
> this core is evidently from PID 16028:
>
> > [New LWP 16028]
>
> If you can identify the exact query that 16028 was running from your logs=
,
> that would be helpful.  Or, if you still have this same core file laying
> about, "p debug_query_string" in gdb would probably be a more trustworthy
> guide than trying to match up log entries.
>
> >> That would be nice. I have let pgbench -C run for one hour with select
> >> * from pg_stat_activity running every second (\watch 1) in parallel
> >> but I could not reproduce the issue on HEAD.
>
> Yeah, I tried similar experiments without result.  Presumably there is
> some other triggering condition here, but it's hard to guess what.
> I tried things like doing VACUUM FULL on pg_database and pg_authid
> to force replan cycles on the view, but no crash.
>
>                         regards, tom lane
>