* 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,
Hi All.
I've found a memory-leak bug in PostgreSQL 9.1.9's background
writer process.
When following parameter is set, it occurs every time CHECKPOINT runs.
wal_level = hot_standby
I've also confirmed REL9_1_STABLE and it is not fixed yet.
In additional, it also occurs in 9.3.beta1's checkpo
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
Hello
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_ident($2) || ' = ' || quote_literal(
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
>
Hi,
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
until the backend exits (user disconnects). We've
Resend attempt -- previous attempt rejected for size. I have NOT
attached the PostgreSQL log (110kB) to this attempt.
--
We had an odd problem the other night which appears to be a rare but
serious bug in PostgreSQL 8.2.4. I don't see anything in the release
notes to indicate that thi
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
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.
I used Valgrind(http://valgrind.kde.org/)
which is an open source memory profiler application in order to find the
problem.
Machine: Pentium 4
OS: Linux
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)---
Hello.
I found that strange behaviour:
gsbusb=# select g.cod, (select count(*) from scatt where grotta=g.cod)
as att, count(*) from grotte g, immagine i, scatt a where
i.scattata_in=g.cod group by g.cod, att;
NOTICE: PortalHeapMemoryFree: 0x0x8233790 not in alloc set!
NOTICE: Buffer Leak: [056]
If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to [EMAIL PROTECTED]
To report any other bug, fill out the form below and e-mail it to
[EMAIL PROTECTED]
If you not only found the prob
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
I am running a PostgreSQL 7.1.3 on a Intel Pentium III
My operating system is SuSE Linux 7.1 with Kernel 2.4.4 (ELF)
I compiled postgresql with gcc 2.95.2
My problem:
when using "vacuum analyze " on very large tables (I have one
with about 30GB) the memory usage increases continues until no memo
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 am running a PostgreSQL 7.1.3 on a Intel Pentium III
My operating system is SuSE Linux 7.1 with Kernel 2.4.4 (ELF)
I compiled postgresql with gcc 2.95.2
My problem:
when using "vacuum analyze " on very large tables (I have one
with about 30GB) the memory usage increases continues until no memo
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Sullivan
> Sent: Monday, June 18, 2001 2:59 AM
> To: [EMAIL PROTECTED]
> Subject: [BUGS] Memory leak in 7.0.3 JDBC driver
>
>
>
> Hi,
>
> I'm running P
;<<<<<<<<<<
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
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 AS3AP, TPC-C, and TPC-D
benchmarks using 1 to 100 users. Our benchmarking
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
Craig Schlenter ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
memory leak while using cursors
Long Description
Hi
I'm trying to get a large result set back from a postgres 7.02
database and am bumping my head into the limita
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
Hello Developers,
at first, thank you for the wonderful work you did on the excellent
database.
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 d
42 matches
Mail list logo
