Re: segmentation fault postgres 9.3.5 core dump perlu related ?

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: "Day, David" <dday(at)redcom(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: segmentation fault postgres 9.3.5 core dump perlu related ?
Date: 2015-01-29 20:30:10
Message-ID: CAFaPBrQBCTsKeq9N7Z4gEYnXcnOgVng0Cy=Uty-V867H+jM04Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Jan 29, 2015 at 8:40 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Day, David" <dday(at)redcom(dot)com> writes:
> > I am amending the info threads info there are two threads.
>
> Well, that's your problem right there. There should never, ever be more
> than one thread in a Postgres backend process: none of the code in the
> backend is meant for a multithreaded situation, and so there are no
> interlocks on global variable access etc.
>

One thing you might try is setting a breakpoint on pthread_create (or
perhaps clone?) and see if that gives any clues as to what is spawning the
thread. If that doesn't help, I would try commenting out large chunks of
the plperlu function until the break point is not tripped, trying to find
what line causes it. It might also be interesting to see what happens if
you try with a non thread enabled perl-- but AFAICT nothing in
cc.get_sip_id() should cause threads to be used. A very quick grep of the
perl source seems to confirm this. Maybe something in the URI module?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Sterpu Victor 2015-01-29 20:36:07 Re: Subselect with no records results in final empty set
Previous Message Sterpu Victor 2015-01-29 20:22:28 Re: Subselect with no records results in final empty set