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 memor
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 actually the part of
> > t
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 cons
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 Free, 98% Inuse
> >> OK, but why do we then g
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 judging from the name of th
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 function, I would bet this is
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 further details from the original FreeBSD 10.1 ma
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 Cache, 1661M Buf, 30M Free
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 USERNAMETHR PRI NICE
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
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
consum
On Sat, Jul 5, 2014 at 11:06 AM, Madhurima Das 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)
>{
> fprintf(stderr, "Co
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 = PQconnectdb
Eric Ridge 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 slowly until i
# select version();
version
---
PostgreSQL 9.
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 07:09:27.
On Tue, Jan 10, 2012 at 6:48 PM, Michael P. Soulier
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
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
(vg_replace_malloc.c:
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 :
> Craig Ringer writes:
>> Even better, add a valgrind suppressions file for the warnings and
>> ignore them. They are "leaks" only in the se
Craig Ringer 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 genuine problems. Yo
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 OpenSS
Antonio Vieiro 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 still
there when the
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 /lib/libcrypt
2011/4/5 Jorge Arévalo :
> 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
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
Craig Ringer 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 more sense, sin
On Tue, 2009-07-21 at 10:13 -0400, Tom Lane wrote:
> Craig Ringer 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
Craig Ringer 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.
regards, tom la
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
wro
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
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 leak
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
Sorry for the reply-to-self, but I thought I'd take ecpg out of the
equation:
#include
#include
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 information li
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
tgres 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:
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
-
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 t
On 12/8/05, Martijn van Oosterhout 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 document
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 te
> 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?
--
Kath
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 se
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%
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 postmaster
] on behalf of hubert depesz 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.
> ***-*
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
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
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
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 '', passwo
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
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(
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
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.)
Afte
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 b
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
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 20
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: [GEN
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 rec
'[EMAIL PROTECTED]'
> Subject: 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 compl
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
> explanati
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 t
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 with
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 libpq
>
>
> 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 b
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
>
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
It just caused a backend to grow to 133 MB in 4 hours running, which is
obviously not good
Simple piece of C code to demonstrate this:
65 matches
Mail list logo