* 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
13 matches
Mail list logo
