Re: assessing parallel-safety

On Fri, Mar 20, 2015 at 11:08 AM, Thom Brown <thom(at)linux(dot)com> wrote:
> On 20 March 2015 at 15:02, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Fri, Mar 20, 2015 at 10:24 AM, Thom Brown <thom(at)linux(dot)com> wrote:
>>> 2015-03-20 14:19:31 GMT [4273]: [78-1] user=,db=,client= DEBUG:
>>> server process (PID 4285) was terminated by signal 11: Segmentation
>>> fault
>>
>> Any chance you can get us a stack backtrace of this crash?
>
> (gdb) cont
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000770843 in pfree ()
> (gdb) bt
> #0 0x0000000000770843 in pfree ()
> #1 0x00000000005a382f in ExecEndFunnel ()
> #2 0x000000000059fe75 in ExecEndAppend ()
> #3 0x00000000005920bd in standard_ExecutorEnd ()
> #4 0x000000000055004b in ExplainOnePlan ()
> #5 0x000000000055025d in ExplainOneQuery ()
> #6 0x000000000055064d in ExplainQuery ()
> #7 0x0000000000680db1 in standard_ProcessUtility ()
> #8 0x000000000067e1c1 in PortalRunUtility ()
> #9 0x000000000067ef1d in FillPortalStore ()
> #10 0x000000000067f8eb in PortalRun ()
> #11 0x000000000067d628 in PostgresMain ()
> #12 0x0000000000462c5e in ServerLoop ()
> #13 0x000000000062e363 in PostmasterMain ()
> #14 0x00000000004636ad in main ()

OK, thanks. That looks like it's probably the fault of parallel seq
scan patch rather than this one. It would help if you could build
with debug symbols so that we can see line numbers and arguments.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company