On Sat, Jul 11, 2015 at 10:07 PM, Michael Bommarito <
michael@bommaritollc.com> wrote:
> Here is the offending query and gdb session/stacktrace output. Please
> let me know if we can provide anything else from gdb or logs that can be
> anonymized.
>
Thanks.
> 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()
>
12803 is the number of the process PID, right?
[...]
> Core was generated by `postgres: postgres databasename 127.0.0.1(42063)
> BIND '.
>
Interesting. So you are using the extended query protocol.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 get_tle_by_resno (tlist=0x7fd0d5da27c0, resno=resno@entry=6) at
> /tmp/buildd/postgresql-9.5-9.5~alpha1/build/../src/backend/parser/parse_relation.c:2832
> 2832
> /tmp/buildd/postgresql-9.5-9.5~alpha1/build/../src/backend/parser/parse_relation.c:
> No such file or directory.
> (gdb) bt
> #0 get_tle_by_resno (tlist=0x7fd0d5da27c0, resno=resno@entry=6) at
> /tmp/buildd/postgresql-9.5-9.5~alpha1/build/../src/backend/parser/parse_relation.c:2832
> #1 0x00007fd0d47cb9dd in pullup_replace_vars_callback
> (var=0x7fd0d5d9e958, context=0x7fff52170620) at
> /tmp/buildd/postgresql-9.5-9.5~alpha1/build/../src/backend/optimizer/prep/prepjointree.c:2074
> [...]
> #15 0x00007fd0d4929760 in BuildCachedPlan (plansource=plansource@entry=0x7fd0d5d7d940,
> qlist=0x7fd0d5d30cf8, qlist@entry=0x0, boundParams=boundParams@entry=0x0)
> at
> /tmp/buildd/postgresql-9.5-9.5~alpha1/build/../src/backend/utils/cache/plancache.c:951
>
And the crash happens in the planner when building a cached plan. This may
be enough information for coming up with a reproducible test case. I'll get
a closer look on Monday.
--
Michael