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
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 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
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
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
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
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
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
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
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
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
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)
{
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 =
# select version();
version
---
PostgreSQL
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
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
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);
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
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
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
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
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.
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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?
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
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
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
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
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
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
64 matches
Mail list logo