Yes, 12803 was the PID of the parent postgres process.
While the extend query protocol was being used by this client and query,
we've also been able to trigger it via unprepared statements in `psql` or
pgAdmin.
Great, thank you! I'll keep the core around for now so we can provide
additional details; if we need to test another execution path for segfault,
it will need to wait until the weekend again.
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 9:18 AM, Michael Paquier <michael.paquier@gmail.com>
wrote:
>
>
> 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
>