Skip site navigation (1) Skip section navigation (2)

Re: libgcc double-free, backend won't die

From: Craig James <craig_james(at)emolecules(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org
Subject: Re: libgcc double-free, backend won't die
Date: 2007-12-16 19:03:11
Message-ID: 4765766F.9000902@emolecules.com (view raw or flat)
Thread:
Lists: pgsql-performance
Gregory Stark wrote:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 
>> James Mansion <james(at)mansionfamily(dot)plus(dot)com> writes:
>>> 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?
>> Yes.
>> 1) It's of no value to us

Who is "us"?  Some of us would like to use the system for advanced scientific work, and scientific libraries are usually written in C++.

>> 2) On many platforms there is a nonzero performance penalty

I'm surprised you say this, given that you're usually the voice of reason when it comes to rejecting hypothetical statements in favor of tested facts.  If building Postgres using thread-safe technology is really a performance burden, that could be easily verified.  A "nonzero performance penalty", what does that mean, a 0.0001% slowdown?  I find it hard to believe that the performance penalty of thread-safe version would even be measurable.

If nobody has the time to do such a test, or other priorities take precedence, that's understandable.  But the results aren't in yet.

> 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.

The "one small range of glibc versions" is a giveaway.  I've seen this problem in FC3, 5, and 6 (I went through this series of upgrades all in one week trying to fix this problem).  With each version, I recompiled Postgres and OpenBabel from scratch.  I'm going to try FC7 next since it's now the only "official" supported version, but I don't believe glibc is the problem.

Andrew Dalke, a regular contributor to the OpenBabel forum, suggests another problem: It could be a result of linking the wrong libraries together.  The gcc/ld system has a byzantine set of rules and hacks that if I understand Andrew's posting) select different versions of the same library depending on what it thinks you might need.  It's possible that the wrong version of some system library is getting linked in.

Craig

In response to

Responses

pgsql-performance by date

Next:From: Steinar H. GundersonDate: 2007-12-16 19:03:47
Subject: Re: SELECT * FROM table is too slow
Previous:From: Merlin MoncureDate: 2007-12-16 18:52:00
Subject: Re: update 600000 rows

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group