Re: Postgres gets stuck

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com>
Cc: Chris <dmagick(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgres gets stuck
Date: 2006-05-12 02:51:12
Message-ID: 19950.1147402272@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Craig A. James" <cjames(at)modgraph-usa(dot)com> writes:
> 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.

Correct. palloc/pfree are all about managing the lifetime of memory
allocations, so that (for example) a function can return a palloc'd data
structure without worrying about whether that creates a long-term memory
leak. But ultimately they just use malloc/free, and there's certainly
not any threading or mutex considerations in there.

> No threading anywhere. None of the libraries use threads or mutexes. It's just plain old vanilla C/C++ scientific algorithms.

Darn, my best theory down the drain.

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

Let us know how it goes...

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Bruno Wolff III 2006-05-12 07:19:57 Re: Arguments Pro/Contra Software Raid
Previous Message Craig A. James 2006-05-12 02:10:17 Re: Postgres gets stuck