| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Naoya Anzai <anzai-naoya(at)mxu(dot)nes(dot)nec(dot)co(dot)jp>, pgsql-bugs(at)postgresql(dot)org, Akio Iwaasa <iwaasa(at)mxs(dot)nes(dot)nec(dot)co(dot)jp> |
| Subject: | Re: Memory-leak in BackgroundWriter(and Checkpointer) |
| Date: | 2013-06-04 13:23:00 |
| Message-ID: | 51ADEA34.4080704@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 04.06.2013 15:27, Stephen Frost wrote:
> * Naoya Anzai (anzai-naoya(at)mxu(dot)nes(dot)nec(dot)co(dot)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, ala what GetRunningTransactionData() does, and
> avoid having to do allocation while holding all the locks (or at least,
> not very often).
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 complaints of latency hiccups with
wal_level=hot_standby.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-06-04 13:27:58 | Re: Memory-leak in BackgroundWriter(and Checkpointer) |
| Previous Message | Andres Freund | 2013-06-04 13:14:07 | Re: BUG #8192: On very large tables the concurrent update with vacuum lag the hot_standby replica |