To: "Magnus Hagander" <magnus@hagander.net>
Cc: "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
In-Reply-To: <20071211155703.GT31937@svr2.hagander.net> (Magnus Hagander's
	message of "Tue\, 11 Dec 2007 16\:57\:03 +0100")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
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>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Tue, 11 Dec 2007 17:02:56 +0000
Message-ID: <87r6htw4e7.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Magnus Hagander" <magnus@hagander.net> writes:

> On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote:
>
>> This should be amended to say,
>> 
>>  "To be precise, a non-threaded, shared library needs to be created."
>
> Just before someone goes ahead and writes it (which is probably a good idea
> in general), don't write it just like taht - because it's platform
> dependent. On win32, you can certainly stick a threaded library to it -
> which is good, because most (if not all) win32 libs are threaded... Now, if
> they actually *use* threads explicitly things might break (but most likely
> not from that specifically), but you can link with them without the
> problem. I'm sure there are other platforms with similar situations.

Even on Unix there's nothing theoretically wrong with loading a shared library
which uses threads. It's just that there are a whole lot of practical problems
which can crop up.

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.

So you're pretty much restricted to calling Postgres API functions from the
main stack which means from the original thread Postgres loaded you with.

Then there's

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.

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.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's On-Demand Production Tuning