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

Поиск
Список
Период
Сортировка
От Craig James
Тема Re: libgcc double-free, backend won't die
Дата
Msg-id 4765766F.9000902@emolecules.com
обсуждение исходный текст
Ответ на Re: libgcc double-free, backend won't die  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: libgcc double-free, backend won't die  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-performance
Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
>> James Mansion <james@mansionfamily.plus.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
usuallywritten 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
statementsin favor of tested facts.  If building Postgres using thread-safe technology is really a performance burden,
thatcould be easily verified.  A "nonzero performance penalty", what does that mean, a 0.0001% slowdown?  I find it
hardto 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'tin 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
completelymisleading 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
seriesof upgrades all in one week trying to fix this problem).  With each version, I recompiled Postgres and OpenBabel
fromscratch.  I'm going to try FC7 next since it's now the only "official" supported version, but I don't believe glibc
isthe problem. 

Andrew Dalke, a regular contributor to the OpenBabel forum, suggests another problem: It could be a result of linking
thewrong 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
thewrong version of some system library is getting linked in. 

Craig

В списке pgsql-performance по дате отправления:

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: update 600000 rows
Следующее
От: "Steinar H. Gunderson"
Дата:
Сообщение: Re: SELECT * FROM table is too slow