I'll try to generate an isolated core dump and stack trace this weekend
when the system is not in use.
I also confirmed that the earlier patch
2897e069c1f4309a237a1fa4bf5d2fcd9c4b9868 for 12918 is applied in our
version, so either the patch didn't handle all cases or it's unrelated.
Thanks,
Michael J. Bommarito II, CEO
Bommarito Consulting, LLC
*Web:* http://www.bommaritollc.com
*Mobile:* +1 (646) 450-3387
On Tue, Jul 7, 2015 at 9:17 PM, Michael Paquier <michael.paquier@gmail.com>
wrote:
> On Wed, Jul 8, 2015 at 1:52 AM, <michael@bommaritollc.com> wrote:
> > Environment: Up-to-date instance running Trusty and using
> apt.postgresql.org
> > postgresql-9.5-alpha1. Database was upgraded using pg_dump/restore. All
> > other application behavior as expected.
> >
> > Not sure if this is related to #13286 or #12918, but if so, still
> affecting
> > the binaries in apt. Pretty critical to fly blind without access to
> this.
> >
> > Crash example 1:
> > 2015-07-07 16:42:45 UTC [26785-2] LOG: server process (PID 11836) was
> > terminated by signal 11: Segmentation fault
> > 2015-07-07 16:42:45 UTC [26785-3] DETAIL: Failed process was running:
> > select * from pg_stat_activity ;
> >
> > Crash example 2:
> > https://github.com/ankane/pghero/issues/30
>
> If this link gets away we would lost the test case, it is better to
> directly add it in the email:
> SELECT pid, state, application_name AS source, age(now(), xact_start)
> AS duration, waiting, query, xact_start AS started_at FROM
> pg_stat_activity WHERE query <> '<insufficient privilege>' AND s
> tate <> 'idle' AND pid <> pg_backend_pid() AND now() - query_start >
> interval '60 seconds' ORDER BY query_start DESC;
>
> This seems unrelated to #13286 which refers to pg_terminate_backend()
> crashing, and in the case 1 presented above the query used for the
> crash is more simple. Now this may be related to #12918, so could it
> be possible to see at least a stack trace to see what is the code path
> failing?
> --
> Michael
>