Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 1E0882E02C6
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Sun, 16 Dec 2007 13:46:05 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 87665-06 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Sun, 16 Dec 2007 13:46:00 -0400 (AST)
Received: from ptb-relay03.plus.net (ptb-relay03.plus.net [212.159.14.214])
	by postgresql.org (Postfix) with ESMTP id B97AB2E02EE
	for <pgsql-performance@postgresql.org>;
	Sun, 16 Dec 2007 13:46:01 -0400 (AST)
Received: from [80.229.150.39] (helo=mansionfamily.plus.com)
	by ptb-relay03.plus.net with esmtp (Exim) id 1J3xYu-000418-8P
	for pgsql-performance@postgresql.org; Sun, 16 Dec 2007 17:46:00 +0000
Received: from [192.168.0.87] ([192.168.0.87]:1451)
	by mansionfamily.plus.com with [XMail 1.22 ESMTP Server]
	id <SD377> for <pgsql-performance@postgresql.org> from
	<james@mansionfamily.plus.com>; Sun, 16 Dec 2007 17:51:20 -0000
Message-ID: <476564D6.7090702@mansionfamily.plus.com>
Date: Sun, 16 Dec 2007 17:48:06 +0000
From: James Mansion <james@mansionfamily.plus.com>
Organization: MsgWare
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Gregory Stark <stark@enterprisedb.com>
CC: Magnus Hagander <magnus@hagander.net>,
	Craig James <craig_james@emolecules.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>, pgsql-performance@postgresql.org
Subject: Re: libgcc double-free, backend won't die
References: <4729B1E9.2080306@gmail.com> <475E4133.5080009@emolecules.com>
	<20071211112128.GB4708@alvh.no-ip.org>
	<475EA754.1090307@emolecules.com>
	<20071211151416.GD10710@alvh.no-ip.org>
	<475EA9FD.9000706@emolecules.com>
	<20071211152010.GE10710@alvh.no-ip.org> <475EAB69.9@emolecules.com>
	<20071211152838.GH4708@alvh.no-ip.org>
	<475EB1B9.3000405@emolecules.com>
	<20071211155703.GT31937@svr2.hagander.net>
	<87r6htw4e7.fsf@oxford.xeocode.com>
In-Reply-To: <87r6htw4e7.fsf@oxford.xeocode.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200712/241
X-Sequence-Number: 28057

Gregory Stark wrote:
> 1) No Postgres function is guaranteed to be thread-safe so you better protect
>    against concurrent calls to Postgres API functions. Also Postgres functions
>    use longjmp which can restore the stack pointer to a value which may have
>    been set earlier, possibly by another thread which wouldn't work.
>
>   
That's a whole different thing to saying that you can't use a threaded 
subsystem under a Postgres
process.

> 2) Some OSes have bugs (notably glibc for a specific narrow set of versions)
>    and don't expect to have standard library functions called before
>    pthread_init() then called again after pthread_init(). If they expect the
>    system to be either "threaded" or "not threaded" then they may be surprised
>    to see that state change.
>
>   
Is there any particular reason not to ensure that any low-level 
threading support in libc is enabled right
from the get-go, as a build-time option?  Does it do anything that's not 
well defined in a threaded
process?  Signal handling and atfork (and posix_ exec) are tyical areas 
I guess.  While this can potentially
make malloc slower, Postgres already wraps malloc so using a caching 
thread-aware malloc
substitute such as nedmalloc should be no problem.

I don't see any issue with the setjmp usage - so long as only one thread 
uses any internal API.  Which
can be checked rather easily at runtime with low cost in a debug build.
> That just means you have to use a non-buggy version of your OS. Unfortunately
> tracking down bugs in your OS to figure out what's causing them and whether
> it's a particular known bug can be kind of tricky.
>   
Is that really much of an issue an the  current version of any major OS 
though?  Its reaonable to
limit the use of a threaded library (in particular, the runtimes for 
most embeddable languages, or
libraries for RPC runtimes, etc) to 'modern' platforms that support 
threads effectively.  On
many such platforms these will already implicitly link libpthread anyway.

James