Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 59F882E0208 for ; Sun, 16 Dec 2007 16:06:56 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 11580-06 for ; Sun, 16 Dec 2007 16:06:52 -0400 (AST) Received: from oxford.xeocode.com (unknown [87.127.95.196]) by postgresql.org (Postfix) with ESMTP id 5973C2E0203 for ; Sun, 16 Dec 2007 16:06:52 -0400 (AST) Received: from localhost ([127.0.0.1] helo=oxford.xeocode.com) by oxford.xeocode.com with esmtp (Exim 4.67) (envelope-from ) id 1J3zlA-0000oC-69; Sun, 16 Dec 2007 20:06:48 +0000 To: "Craig James" Cc: "Tom Lane" , Subject: Re: libgcc double-free, backend won't die In-Reply-To: <4765766F.9000902@emolecules.com> (Craig James's message of "Sun\, 16 Dec 2007 11\:03\:11 -0800") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX" 54583) 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> <476564D6.7090702@mansionfamily.plus.com> <27316.1197828101@sss.pgh.pa.us> <877ijeqzd9.fsf@oxford.xeocode.com> <4765766F.9000902@emolecules.com> From: Gregory Stark Organization: EnterpriseDB Date: Sun, 16 Dec 2007 20:06:47 +0000 Message-ID: <87zlwapfoo.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/249 X-Sequence-Number: 28065 "Craig James" writes: > Gregory Stark wrote: > >> And the only reason to do that would be to work around one bug in one small >> range of glibc versions. If you're going to use a multi-threaded library >> (which isn't very common since it's hard to do safely for all those other >> reasons) surely using a version of your OS without any thread related bugs is >> a better idea. > > You're jumping ahead. This problem has not been accurately diagnosed yet. It > could be that the pthreads issue is completely misleading everyone, and in fact > there is a genuine memory corruption going on here. Or not. We don't know yet. > I have made zero progress fixing this problem. Well, no that would be you jumping ahead then... You proposed Postgres changing the way it handles threaded libraries based on Tom's suggestion that your problem was something like the glibc problem previously found. My comment was based on the known glibc problem. From what you're saying it's far from certain that the problem would be fixed by changing Postgres's behaviour in the way you proposed. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning