* Pawel Kozik (pawel.ko...@alcatel-lucent.com) wrote:
> Any idea when it will be available in official PostgreSQL release 9.1.x or
> 9.2.x ?
Yes, the next set of point releases should include Tom's patch to fix
this leak.
Thanks,
Stephen
signature.asc
Description: Digi
Any idea when it will be available in official PostgreSQL release 9.1.x or
9.2.x ?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Memory-leak-in-BackgroundWriter-and-Checkpointer-tp5757869p5758783.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com
Tom, Stephen, Heikki and Andres,
You do FAST work!
Thanks for your prompt responses.
---
Naoya Anzai
NEC Soft,Ltd.
http://www.necsoft.com/eng/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm already working on back-patching the attached.
Works for me,
Thanks!
Stephen
signature.asc
Description: Digital signature
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I think the proposed fix is fine code-wise; the real problem here is
>> crummy commenting. GetRunningTransactionLocks isn't documented as
>> returning a palloc'd array, and why the heck do we have a long comment
>> about its implem
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Meh. I'm not impressed with permanently allocating an array large
> enough to hold all the locks GetRunningTransactionLocks
> might return --- that's potentially much larger than the other array,
> and in fact I don't think we have a hard limit on its size
* Andres Freund (and...@2ndquadrant.com) wrote:
> Seems more consistent with the rest of the code too. But anyway, I am
> fine with fixing it either way.
Patch attached which mirrors what GetRunningTransactionData() (the other
function called from LogStandbySnapshot) does, more-or-less- uses a
sta
Stephen Frost writes:
> * Andres Freund (and...@2ndquadrant.com) wrote:
>> Seems more consistent with the rest of the code too. But anyway, I am
>> fine with fixing it either way.
> And this is really the other point- having LogStandbySnapshot() need to
> clean up after GetRunningTransactionLocks
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-06-04 16:23:00 +0300, Heikki Linnakangas wrote:
> > I can't get too excited about the overhead of a single palloc here. It's a
> > fairly heavy operation anyway, and only runs once per checkpoint. And we
> > haven't heard any actual complain
On 2013-06-04 16:23:00 +0300, Heikki Linnakangas wrote:
> On 04.06.2013 15:27, Stephen Frost wrote:
> >* Naoya Anzai (anzai-na...@mxu.nes.nec.co.jp) wrote:
> >>I've found a memory-leak bug in PostgreSQL 9.1.9's background
> >>writer process.
> >
> >This looks legit, but probably not the right appro
On 04.06.2013 15:27, Stephen Frost wrote:
* Naoya Anzai (anzai-na...@mxu.nes.nec.co.jp) wrote:
I've found a memory-leak bug in PostgreSQL 9.1.9's background
writer process.
This looks legit, but probably not the right approach to fixing it.
Looks like it'd be better to work out a way to use a
* Naoya Anzai (anzai-na...@mxu.nes.nec.co.jp) wrote:
> I've found a memory-leak bug in PostgreSQL 9.1.9's background
> writer process.
This looks legit, but probably not the right approach to fixing it.
Looks like it'd be better to work out a way to use a static variable to
reuse the same memory,
2011/10/11 Tom Lane :
> Pavel Stehule writes:
>> I found a following issue (tested on PostgreSQL 9.2)
>
>> CREATE OR REPLACE FUNCTION public.setfield(a anyelement, text, text)
>> RETURNS anyelement
>> LANGUAGE plpgsql
>> AS $function$
>> begin
>> create temp table aux as select $1.*;
>> execut
Pavel Stehule writes:
> I found a following issue (tested on PostgreSQL 9.2)
> CREATE OR REPLACE FUNCTION public.setfield(a anyelement, text, text)
> RETURNS anyelement
> LANGUAGE plpgsql
> AS $function$
> begin
> create temp table aux as select $1.*;
> execute 'update aux set ' || quote_iden
Dne 14.12.2010 21:50, Robert Haas napsal(a):
> On Fri, Nov 26, 2010 at 7:54 AM, wrote:
>> one of my colleagues found ugly memory leak in the xml2 contrib module.
>> Try this:
>>
>> select xpath_number('' || generate_series || '','/data') from
>> generate_series(1,50);
>>
>> This will allocate
On Fri, Nov 26, 2010 at 7:54 AM, wrote:
> one of my colleagues found ugly memory leak in the xml2 contrib module.
> Try this:
>
> select xpath_number('' || generate_series || '','/data') from
> generate_series(1,50);
>
> This will allocate arbitrary amount of memory, and it won't release it
>
PROTECTED]
Sent: Tuesday, August 24, 2004 4:13 PM
To: Spencer Quin
Cc: [EMAIL PROTECTED]; Thomas Parry; Geoffrey Stitt
Subject: Re: [BUGS] Memory leak
"Spencer Quin" <[EMAIL PROTECTED]> writes:
> I have found a memory leak in the libpq library for postrgesql 7.4.3.
> The code
"Spencer Quin" <[EMAIL PROTECTED]> writes:
> Tom, I am not sure if my original message made it onto a forum or
> knowledge base but I was wondering if it would be possible for you to
> take it down if it is? There may potentially be some sensitive
> information in it.
The bugs list is archived, y
bject: Re: [BUGS] Memory leak
"Spencer Quin" <[EMAIL PROTECTED]> writes:
> I have found a memory leak in the libpq library for postrgesql 7.4.3.
> The code sample in the attached file will produce the error.
The traceback says that the leak is in libresolv, not libpq. I'
"Spencer Quin" <[EMAIL PROTECTED]> writes:
> I have found a memory leak in the libpq library for postrgesql 7.4.3.
> The code sample in the attached file will produce the error.
The traceback says that the leak is in libresolv, not libpq. I'm not
sure it's really a leak at all --- I'd expect libr
Diego Zuccato <[EMAIL PROTECTED]> writes:
> NOTICE: PortalHeapMemoryFree: 0x0x8233790 not in alloc set!
I'd suggest updating to a newer version of Postgres. That's got to be
7.0 or older.
regards, tom lane
---(end of broadcast)---
Achim =?iso-8859-1?Q?Kr=FCmmel?= <[EMAIL PROTECTED]> writes:
> when using "vacuum analyze " on very large tables (I have one
> with about 30GB) the memory usage increases continues until no memory is
> left and the kernel stops this process.
I don't have 30Gb to spare, but I set up a table of the
Achim =?iso-8859-1?Q?Kr=FCmmel?= <[EMAIL PROTECTED]> writes:
> I suppose this problem is easy to reproduce.
No, it isn't. At the very least, we need the full schema for the
table causing this.
regards, tom lane
---(end of broadcast)--
I posted yesterday regarding a memory leak I found in the JDBC driver in
7.1. I didn't check but it is quite likely it also existed in 7.0. The patch
I created hasn't been checked by anyone else yet so I don't know if it helps
for others or not. Feel free to try it.
--Rainer
> -Original Mess
;<<<<<<<<<<
On 3/9/01, 10:37:10 PM, "Hiroshi Inoue" <[EMAIL PROTECTED]> wrote regarding
RE: [BUGS] Memory leak in ODBC driver:
> > -Original Message-
> > From: [EMAIL PROTECTED]
> >
> > Terry Carlin ([EMAIL PROTECTED]) repo
> -Original Message-
> From: [EMAIL PROTECTED]
>
> Terry Carlin ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> Memory leak in ODBC driver
>
> Long Description
> As part of Great Bridge QA testing, we run the AS
On Sun, Feb 11, 2001 at 12:59:16PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > memory leak while using cursors
>
> > DECLARE BOB CURSOR FOR select date_part('epoch', call_time), date_part('hour',
>call_time), date_part('minute', call_time), date_part('dow', call_time), * from
>call_j
[EMAIL PROTECTED] writes:
> memory leak while using cursors
> DECLARE BOB CURSOR FOR select date_part('epoch', call_time), date_part('hour',
>call_time), date_part('minute', call_time), date_part('dow', call_time), * from
>call_jan where call_time >= '2000/12/16 00:00:00.000' and call_time < '2
doj <[EMAIL PROTECTED]> writes:
> I was experimenting with the 7.1beta3 release. When I use the
> date_part() function in one query several thousand times (in updates for
> example) the postmaster consumes all available memory, until it dies,
> with a "no memory left error". If I execute the same
doj <[EMAIL PROTECTED]> writes:
> It assume that date_part() has a serious memory leak.
> If you like a can reproduce some queries that fail on my machine and
> send them to you with a second email.
Yes, we need to see the exact sequence of queries ...
regards, tom lane
30 matches
Mail list logo
