On Fri, Dec 09, 2005 at 12:15:44PM +0800, Kathy Lo wrote:
See the shmctl() manpage:
int shmctl(int shmid, int cmd, struct shmid_ds *buf);
One of the command ids is IPC_RMID
Do I need to change the source code of postgresql if I want to set
IPC_RMID flag to solve this problem?
On Thu, Dec 08, 2005 at 12:29:11PM +0800, Kathy Lo wrote:
But this shouldn't be an issue here. If you set the IPC_RMID flag then
the kernel should remove the segment when all users go away. This is
standard IPC behaviour and is documentated in the manpage...
Would you please tell me
On 12/8/05, Martijn van Oosterhout kleptog@svana.org wrote:
On Thu, Dec 08, 2005 at 12:29:11PM +0800, Kathy Lo wrote:
But this shouldn't be an issue here. If you set the IPC_RMID flag then
the kernel should remove the segment when all users go away. This is
standard IPC behaviour and is
But this shouldn't be an issue here. If you set the IPC_RMID flag then
the kernel should remove the segment when all users go away. This is
standard IPC behaviour and is documentated in the manpage...
Would you please tell me where to find the manpage and how to set IPC_RMID flag?
--
Kathy
Will Glynn [EMAIL PROTECTED] wrote:
Postgres completely for a few seconds didn't lower the number. It wasn't
taken by any process, which leads me to believe that it's a kernel bug.
If it was a shared memory segment allocated a particular way (I
*think* it's shm_open, I'm not 100%
On Fri, Dec 02, 2005 at 03:53:20PM -0800, Tyler MacDonald wrote:
Will Glynn [EMAIL PROTECTED] wrote:
Postgres completely for a few seconds didn't lower the number. It wasn't
taken by any process, which leads me to believe that it's a kernel bug.
If it was a shared memory segment
hi
i think i've encountered a bug in postgresql 8.1.
yet - i'm not reallty info submitting it to -bugs, as i have no way to
successfully redo it again.
basically
i have server, with dual opteron, 4g of memory, 2gb of swap.
everything working under centos 4.2.
...
what i say is that
even i have observed memory
leaks ... is it happening in postgres side
i can send the valgrind
logs
From: [EMAIL PROTECTED] on
behalf of hubert depesz lubaczewskiSent: Wed 11/30/2005 12:59
PMTo: Jim C. NasbyCc: PostgreSQL
GeneralSubject: Re: [GENERAL] memory leak under heavy
load
lubaczewski
Sent: Wed 11/30/2005 12:59 PM
To: Jim C. Nasby
Cc: PostgreSQL General
Subject: Re: [GENERAL] memory leak under heavy load?
***
Your mail has been scanned by InterScan VirusWall.
***-***
On 11/29/05, Jim C. Nasby [EMAIL PROTECTED] wrote
hi
i think i've encountered a bug in postgresql 8.1.
yet - i'm not reallty info submitting it to -bugs, as i have no way to successfully redo it again.
basically
i have server, with dual opteron, 4g of memory, 2gb of swap. everything working under centos 4.2.
postgresql 8.1 compiled from sources
On 11/29/05, hubert depesz lubaczewski [EMAIL PROTECTED] wrote:
i think i've encountered a bug in postgresql 8.1.
now i'm nearly positive it's a bug.
i created database in this way:
CREATE DATABASE leak;
\c leak
CREATE TABLE users (id serial PRIMARY KEY, username TEXT NOT NULL DEFAULT '',
Are you sure this isn't just PostgreSQL caching data?
A complete testcase would help, too (ie: whatever you used to generate
the initial data).
On Tue, Nov 29, 2005 at 06:46:06PM +0100, hubert depesz lubaczewski wrote:
On 11/29/05, hubert depesz lubaczewski [EMAIL PROTECTED] wrote:
i think
On 11/29/05, Jim C. Nasby [EMAIL PROTECTED] wrote:
Are you sure this isn't just PostgreSQL caching data?
i am not sure. but what bothers me is:
i setup limit of shared memory to 5 buffers - which gives estimate 400 megabytes. how come it ended up using 6GB ?
depesz
13 matches
Mail list logo
