Re: segmentation fault postgres 9.3.5 core dump perlu related ? - Mailing list pgsql-general

From Day, David
Subject Re: segmentation fault postgres 9.3.5 core dump perlu related ?
Date
Msg-id 401084E5E73F4241A44F3C9E6FD79428011405361A@exch-01
Whole thread Raw
In response to Re: segmentation fault postgres 9.3.5 core dump perlu related ?  (Alex Hunsaker <badalex@gmail.com>)
Responses Re: segmentation fault postgres 9.3.5 core dump perlu related ?
List pgsql-general

Thanks for the inputs,  I’ll attempt to apply it and will update when I have some new information. 

 

Thanks

 

 

Dave

 

From: Alex Hunsaker [mailto:badalex@gmail.com]
Sent: Thursday, January 29, 2015 3:30 PM
To: Day, David
Cc: pgsql-general@postgresql.org; Tom Lane
Subject: Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

 

 

 

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

"Day, David" <dday@redcom.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?

pgsql-general by date:

Previous
From: John R Pierce
Date:
Subject: Re: Subselect with no records results in final empty set
Next
From: Adrian Klaver
Date:
Subject: Re: oracle to postgres