From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, noordsij <noordsij(at)cs(dot)helsinki(dot)fi>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #6086: Segmentation fault |
Date: | 2011-07-25 17:18:53 |
Message-ID: | 4E2DA57D.5010100@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 07/25/2011 05:57 PM, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of lun jul 25 11:20:55 -0400 2011:
>> On Sun, Jul 24, 2011 at 5:06 PM, noordsij <noordsij(at)cs(dot)helsinki(dot)fi> wrote:
>>>> Any idea what query triggered this?
>>>
>>> Only up to which stored procedure (which itself contains multiple
>>> statements).
>>
>> If you provide a reproducible test case, we can probably get this fixed.
>>
>> Otherwise, we probably can't.
>
> But why is libxml calling pthread_mutex_lock and such? Unless libxml is
> making itself multithread inside a backend, that shouldn't matter --
> much less cause a crash.
>
> Note (to the OP) that it's totally unexpected to have a Postgres backend
> become multithreaded, and has been shown to be dangerous when a library
> made it so.
well we have seen issues on freebsd in the past with libraries there
being compiled with threading support which caused them to get
ridiculous low stack limits.
Maybe it would be worth trying to recompile the libxml port without
threading support (if that is an option).
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | ZIV - Beratung | 2011-07-25 18:04:16 | TOAST tables bug restoring to PostgreSQL 9.0.4 |
Previous Message | Alvaro Herrera | 2011-07-25 15:57:59 | Re: BUG #6086: Segmentation fault |