Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On 12/13/2015 01:23 PM, Gerhard Wiesinger wrote: On 13.12.2015 21:14, Bill Moran wrote: Wait ... this is a combined HTTP/Postgres server? You didn't mention that earlier, and it's kind of important. What evidence do you have that Postgres is actually the part of this system running out of

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

Hello, some further details from the original FreeBSD 10.1 machine: Mem: 7814M Active, 20G Inact, 2982M Wired, 232M Cache, 1661M Buf, 30M Free Swap: 512M Total, 506M Used, 6620K Free, 98% Inuse PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 77941 pgsql 5 20

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

Hello Bill, Thank you for your response, comments inline: On 13.12.2015 16:05, Bill Moran wrote: On Sun, 13 Dec 2015 09:57:21 +0100 Gerhard Wiesinger wrote: some further details from the original FreeBSD 10.1 machine: Mem: 7814M Active, 20G Inact, 2982M Wired, 232M

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

Gerhard Wiesinger writes: >> Mem: 7814M Active, 20G Inact, 2982M Wired, 232M Cache, 1661M Buf, 30M Free >> Swap: 512M Total, 506M Used, 6620K Free, 98% Inuse > OK, but why do we then get: kernel: swap_pager_getswapspace(4): failed? Just judging from the name of the

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On Sun, 13 Dec 2015 16:35:08 +0100 Gerhard Wiesinger wrote: > Hello Bill, > > Thank you for your response, comments inline: > > On 13.12.2015 16:05, Bill Moran wrote: > > On Sun, 13 Dec 2015 09:57:21 +0100 > > Gerhard Wiesinger wrote: > >> some

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On Sun, 13 Dec 2015 09:57:21 +0100 Gerhard Wiesinger wrote: > > some further details from the original FreeBSD 10.1 machine: > > Mem: 7814M Active, 20G Inact, 2982M Wired, 232M Cache, 1661M Buf, 30M Free > Swap: 512M Total, 506M Used, 6620K Free, 98% Inuse > >PID

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On 13.12.2015 18:17, Tom Lane wrote: Gerhard Wiesinger writes: Mem: 7814M Active, 20G Inact, 2982M Wired, 232M Cache, 1661M Buf, 30M Free Swap: 512M Total, 506M Used, 6620K Free, 98% Inuse OK, but why do we then get: kernel: swap_pager_getswapspace(4): failed? Just

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On 13.12.2015 21:14, Bill Moran wrote: Wait ... this is a combined HTTP/Postgres server? You didn't mention that earlier, and it's kind of important. What evidence do you have that Postgres is actually the part of this system running out of memory? For me the complete picture doesn't look

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On Sun, 13 Dec 2015 20:09:04 +0100 Gerhard Wiesinger wrote: > On 13.12.2015 18:17, Tom Lane wrote: > > Gerhard Wiesinger writes: > >>> Mem: 7814M Active, 20G Inact, 2982M Wired, 232M Cache, 1661M Buf, 30M Free > >>> Swap: 512M Total, 506M Used, 6620K

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On Sun, 13 Dec 2015 22:23:19 +0100 Gerhard Wiesinger wrote: > On 13.12.2015 21:14, Bill Moran wrote: > > Wait ... this is a combined HTTP/Postgres server? You didn't mention that > > earlier, and it's kind of important. > > > > What evidence do you have that Postgres is

[GENERAL] Memory Leak executing small queries without closing the connection

Hello, We are running PostgreSQL 9.4.5 on FreeBSD 10.1 and have multiple worker processes connected via persistent connections to PostgreSQL, they perform just simple queries with SELECT on primary keys and simple INSERTS/UPDATES. Normally nearly all the workers are idle but they still

Re: [GENERAL] memory leak while trying to update/alter column in postgresql

On Sat, Jul 5, 2014 at 11:06 AM, Madhurima Das madhurima@gmail.com wrote: int main() { PGconn *conn; PGresult *res; int i=0,nFields=0,row=0,col=0; conn = PQconnectdb(dbname=test1 host=localhost user=postgres password=yyy); if(PQstatus(conn) == CONNECTION_BAD) {

[GENERAL] memory leak while trying to update/alter column in postgresql

I am trying to update/alter two columns-comment and id in a table called xxx using postgresql. Though the compiler does not show any errors but Valgrind gives major memory leak errors. The code is: int main() { PGconn *conn; PGresult *res; int i=0,nFields=0,row=0,col=0; conn =

[GENERAL] Memory leak with CREATE TEMP TABLE ON COMMIT DROP?

# select version(); version --- PostgreSQL

Re: [GENERAL] Memory leak with CREATE TEMP TABLE ON COMMIT DROP?

Eric Ridge e_ri...@tcdi.com writes: As best I can guess, Postgres has some kind of memory leak around (at least) temporary tables flagged to drop on commit. It's fairly easy to reproduce: I don't see any memory leak with this example. What I do see is the process's use of shared memory grows

[GENERAL] memory leak

Hi, I've written a small multi-threaded C program using libpq, and valgrind is reporting a memory leak. 2012-01-10 13:45:07.263078500 ==12695== 608 bytes in 4 blocks are definitely lost in loss record 19 of 22 2012-01-10 13:45:07.263097500 ==12695==at 0x4005B83: malloc

Re: [GENERAL] memory leak

On Tue, Jan 10, 2012 at 6:48 PM, Michael P. Soulier michael_soul...@mitel.com wrote:    res = PQexec(conn, BEGIN);    if (PQresultStatus(res) != PGRES_COMMAND_OK)    {        fprintf(stderr, DB: BEGIN command failed: %s, PQerrorMessage(conn));        PQclear(res);        exit_nicely(conn);

Re: [GENERAL] memory leak

On 10/01/12 Simon Riggs said: You're missing 2 PQclear() calls on success. http://www.postgresql.org/docs/devel/static/libpq-exec.html#LIBPQ-EXEC-MAIN Ah, thanks. Diffing db.c to db.c@@/main/soulierm_MASTeleworker_dev1/3 --- db.c@@/main/soulierm_MASTeleworker_dev1/3 2011-08-10

Re: [GENERAL] Memory leak somewhere at PQconnectdb?

Hi all, I now know it's somewhat an academic exercise of little practical importance, thanks for the clarification!! Cheers, Antonio 2011/9/2 Tom Lane t...@sss.pgh.pa.us: Craig Ringer ring...@ringerc.id.au writes: Even better, add a valgrind suppressions file for the warnings and ignore

[GENERAL] Memory leak somewhere at PQconnectdb?

Hi all, I'm running one of my programs with valgrind to check for memory leaks and I'm seeing something like this: ==13207== 4 bytes in 1 blocks are still reachable in loss record 1 of 256 ==13207==at 0x4026864: malloc (vg_replace_malloc.c:236) ==13207==by 0x43343BD: ??? (in

Re: [GENERAL] Memory leak somewhere at PQconnectdb?

Antonio Vieiro anto...@antonioshome.net writes: I'm running one of my programs with valgrind to check for memory leaks and I'm seeing something like this: ==13207== 4 bytes in 1 blocks are still reachable in loss record 1 of 256 These are not bugs; they are just permanent allocations that are

Re: [GENERAL] Memory leak somewhere at PQconnectdb?

On 01/09/11 22:08, Antonio Vieiro wrote: Hi all, I'm running one of my programs with valgrind to check for memory leaks and I'm seeing something like this: You only get the one report, though, right? No matter how many times PQconnectdb is run in a loop? It's internal stuff within OpenSSL.

Re: [GENERAL] Memory leak somewhere at PQconnectdb?

Craig Ringer ring...@ringerc.id.au writes: Even better, add a valgrind suppressions file for the warnings and ignore them. They are leaks only in the sense that a static variable is a leak, ie not at all. Yeah, the bottom line here is that valgrind will warn about many things that are not

Re: [GENERAL] Memory leak in SPI_finish call

2011/4/5 Jorge Arévalo jorge.arev...@deimos-space.com: Hello, I'm having problems with a PostgreSQL server side C-function. It's not an aggregate function (operates over a only row of data). When the function is called over tables with ~4000 rows, it causes postgres backend crash with

[GENERAL] Memory leak in SPI_finish call

Hello, I'm having problems with a PostgreSQL server side C-function. It's not an aggregate function (operates over a only row of data). When the function is called over tables with ~4000 rows, it causes postgres backend crash with SEGFAULT. I know the error is a kind of cumulative, because with

Re: [GENERAL] memory leak occur when disconnect database

On Tue, 2009-07-21 at 13:53 +0900, tanjunhua wrote: I get the memory leak scenario not only from Valgrind, but also from the output of top command. At first I think the memory leak occur when I disconnect database by Valgrind, then I write a test sample that just connect and disconnect

Re: ***UNCHECKED*** Re: [GENERAL] memory leak occur when disconnect database

On Tue, 2009-07-21 at 19:39 +0900, tanjunhua wrote: I'm sorry for the twice action. because the mail server reject my response. I should compress it with ciper code(11) and the execute program is compressed also. When I build your example from source I see no indication of anything wrong

Re: ***UNCHECKED*** Re: [GENERAL] memory leak occur when disconnect database

Craig Ringer cr...@postnewspapers.com.au writes: I'm a bit puzzled about why you have three postmaster instances shown as running. It's not unusual for top to show the postmaster's child processes as postmaster as well. Depends on the platform and the options given to top.

Re: ***UNCHECKED*** Re: [GENERAL] memory leak occur when disconnect database

On Tue, 2009-07-21 at 10:13 -0400, Tom Lane wrote: Craig Ringer cr...@postnewspapers.com.au writes: I'm a bit puzzled about why you have three postmaster instances shown as running. It's not unusual for top to show the postmaster's child processes as postmaster as well. Depends on the

Re: ***UNCHECKED*** Re: [GENERAL] memory leak occur when disconnect database

Craig Ringer cr...@postnewspapers.com.au writes: On Tue, 2009-07-21 at 10:13 -0400, Tom Lane wrote: It's not unusual for top to show the postmaster's child processes as postmaster as well. Depends on the platform and the options given to top. Ah. Thanks for clearing that one up. That'd make

Re: [GENERAL] memory leak occur when disconnect database

Because of the three-day break, my response is late. Valgrind is a great tool, but you must learn how to identify false positives and tell the difference between a leak that matters (say 1kb allocated and not freed in a loop that runs once per second) and a leak that doesn't. I get the memory

Re: [GENERAL] memory leak occur when disconnect database

Because of the three-day break, my response is late. 8.1.8 is pretty old. Also you'll have better luck getting help if you actually include the output from Valgrind. the output from Valgrind is not stored. from now on, I will do it again and get the result from Valgrind. PS: the memory

[GENERAL] memory leak occur when disconnect database

I'm running postgres 8.1.8 on Debian and I think memory leak occur when disconnect database. 1. environment setting 1.1 postgresql version: version

Re: [GENERAL] memory leak occur when disconnect database

General Postgres General Subject: [GENERAL] memory leak occur when disconnect database I'm running postgres 8.1.8 on Debian and I think memory leak occur when disconnect database. 1. environment setting 1.1 postgresql version: version

Re: [GENERAL] memory leak occur when disconnect database

Your test case doesn't build, but I've attached a trivially tweaked one that does. Valgrind's report (valgrind --leak-check=full ./test) on my Ubuntu 9.04 machine with Pg 8.3.7 is: ==23382== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 4 ==23382==at

Re: [GENERAL] memory leak occur when disconnect database

Sorry for the reply-to-self, but I thought I'd take ecpg out of the equation: #include sys/types.h #include pwd.h int main() { struct passwd p; struct passwd * r; char buf[500]; getpwuid_r(1000, p, buf[0], 500, r); } ... produces the same leak report. Since you didn't include

Re: [GENERAL] memory leak under heavy load?

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?

Re: [GENERAL] memory leak under heavy load?

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

Re: [GENERAL] memory leak under heavy load?

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

Re: [GENERAL] memory leak under heavy load?

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

Re: [GENERAL] memory leak under heavy load?

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%

Re: [GENERAL] memory leak under heavy load?

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

Re: [GENERAL] memory leak under heavy load?

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

Re: [GENERAL] memory leak under heavy load?

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

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

[GENERAL] memory leak under heavy load?

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

Re: [GENERAL] memory leak under heavy load?

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 '',

Re: [GENERAL] memory leak under heavy load?

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

Re: [GENERAL] memory leak under heavy load?

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

Re: [GENERAL] memory leak of PQmakeEmptyPGresult?

hi,Gaetano Mendola: you wrote: Ann wrote: I found the reason of this question and fixed the bug :)) Why then don't you share it ? em ,because i make a stupid mistake in programming!! :(( I made use of transactions to ensure database consistency, and then, i called PQexec() to

Re: [GENERAL] memory leak of PQmakeEmptyPGresult??

Ann wrote: I found the reason of this question and fixed the bug :)) Why then don't you share it ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

[GENERAL] memory leak of PQmakeEmptyPGresult??

I try to detect potential memory management bugs of my program with valgrind. (PostgreSQL is at version 8.0 beta2. Operating System is Red Hat Enterprise Linux 3. Valgrind is at version 2.2.0.) After Program terminated, Valgrind reports a memory lost error information as follows:==13524== 208

Re: [GENERAL] memory leak of PQmakeEmptyPGresult??

I found the reason of this question and fixed the bug :))xiaoling he [EMAIL PROTECTED] wrote: I try to detect potential memory management bugs of my program with valgrind. (PostgreSQL is at version 8.0 beta2. Operating System is Red Hat Enterprise Linux 3. Valgrind is at version 2.2.0.) After

Re: [GENERAL] Memory Leak

Here is a sample of the code which demonstrates the memory problem I am having. The problem does not occur immediately after memory has been maxed out. It appears that there is an attempt to recover some memory, about 1 Kbytes, once max is near. This works for about a half a day to one full

[GENERAL] Memory Leak

Hello, RedHat 7.0, Postgres 7.1 (libpq), Intel Cel 433, 64mb, 15g hd. I am running a test which performs 1000 transactions of 1000 updates of a single column in a single table, or (1 tranaction = 1000 updates) * 1000. I have no indecies for any of the columns and the table has 3 columns and

[GENERAL] Memory leak in FreeBSD?

We upgraded to version 6.5.2 recently, running on FreeBSD 3.0. Now we are having problems with moderately complex queries failing to complete (backend terminating unexpectedly; last one crashed the server). The most likely explanation appears to be a memory leak. Is there any known problem

Re: [GENERAL] Memory leak in FreeBSD?

On Tue, 11 Jan 2000, Jeff Eckermann wrote: We upgraded to version 6.5.2 recently, running on FreeBSD 3.0. Now we are having problems with moderately complex queries failing to complete (backend terminating unexpectedly; last one crashed the server). The most likely explanation appears to

Re: [GENERAL] Memory leak in FreeBSD?

Did you upgrade from source or from the freebsd ports? We upgraded to version 6.5.2 recently, running on FreeBSD 3.0. Now we are having problems with moderately complex queries failing to complete (backend terminating unexpectedly; last one crashed the server). The most likely explanation

RE: [GENERAL] Memory leak in FreeBSD?

: Re: [GENERAL] Memory leak in FreeBSD? Did you upgrade from source or from the freebsd ports? We upgraded to version 6.5.2 recently, running on FreeBSD 3.0. Now we are having problems with moderately complex queries failing to complete (backend terminating unexpectedly; last one

RE: [GENERAL] Memory leak in FreeBSD?

What is maxusers set to in your kernel? One prolem I had was that postgresql was using more filedescriptors that my kernel could handle. If you'd like to check your current filedescriptor status and your max, try: pstat -T. If that is your problem, change your maxusers to a suitable number and

RE: [GENERAL] Memory leak in FreeBSD?

Maxusers is set to 128. RAM is 256Mg. Do you think this could be the problem? -Original Message- From: admin [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, January 11, 2000 12:50 PM To: Jeff Eckermann Cc: '[EMAIL PROTECTED]' Subject: RE: [GENERAL] Memory leak in FreeBSD? What

[GENERAL] Memory leak in libpq libpq++?

Using the distributed examples as a guide, I wrote a c++ code to execute a large suite of queries. Each query opens and closes a backend. I notice a *big leak* when large numbers of tuples are returned. I get the same behavior using libpq (with PQclears and PQ finishes explicitly) or using

Re: [GENERAL] Memory leak

What version of PostgreSQL? The "backends dying problem", I thought, was fixed already... On Wed, 25 Aug 1999, Michael wrote: Hi all I have just isolated a big problem in one of my applications and it turns out to be a memory leak in postgresql on a VERY basic piece of functionality

Re: [GENERAL] Memory leak

What version of PostgreSQL? The "backends dying problem", I thought, was fixed already... = select version(); version -- PostgreSQL 6.5.1 on i586-pc-linux-gnu, compiled by