From: Craig A. James <cjames@modgraph-usa.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Chris <dmagick@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Postgres gets stuck
Date: Thu, 11 May 2006 19:10:17 -0700
Message-ID: <4463EE89.8010103@modgraph-usa.com> (raw)
In-Reply-To: <18707.1147392206@sss.pgh.pa.us>
References: <446135F9.1060608@modgraph-usa.com>
<4461391D.2000800@gmail.com>
<44635DFE.1060509@modgraph-usa.com>
<18707.1147392206@sss.pgh.pa.us>
Tom Lane wrote:
> >My suspicion is that it's an incompatibility between malloc()
> >libraries.
>
> On Linux there's only supposed to be one malloc, ie, glibc's version.
> On other platforms I'd be worried about threaded vs non-threaded libc
> (because the backend is not threaded), but not Linux.
I guess I misinterpreted the Postgress manual, which says (in 31.9, "C Language Functions"),
"When allocating memory, use the PostgreSQL functions palloc and pfree
instead of the corresponding C library functions malloc and free."
I imagined that perhaps palloc/pfree used mutexes for something. But if I understand you, palloc() and pfree() are just wrappers around malloc() and free(), and don't (for example) make their own separate calls to brk(2), sbrk(2), or their kin. If that's the case, then you answered my question - it's all ordinary malloc/free calls in the end, and that's not the source of the problem.
> There may be a more basic threading problem here, though, rooted in the
> precise fact that the backend isn't threaded. If you're trying to use
> any libraries that assume they can have multiple threads, I wouldn't be
> at all surprised to see things go boom.
No threading anywhere. None of the libraries use threads or mutexes. It's just plain old vanilla C/C++ scientific algorithms.
> C++ exception handling could be problematic too.
No C++ exceptions are thrown anywhere in the code, 'tho I suppose one of the I/O libraries could throw an exception, e.g. when reading from a file. But there's no evidence of this after millions of identical operations succeeded. In addition, the stack trace shows it to be stuck in a memory operation, not an I/O operation.
> Or it could be a garden variety glibc bug. How up-to-date is your
> platform?
I guess this is the next place to look. From the few answers I've gotten, it sounds like this isn't a known Postgres issue, and my stack trace doesn't seem to be familiar to anyone on this forum. Oh well... thanks for your help.
Craig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: cjames@modgraph-usa.com, tgl@sss.pgh.pa.us, dmagick@gmail.com
Subject: Re: Postgres gets stuck
In-Reply-To: <4463EE89.8010103@modgraph-usa.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox