Re: BUG #12910: Memory leak with logical decoding - Mailing list pgsql-bugs

From Andres Freund
Subject Re: BUG #12910: Memory leak with logical decoding
Date
Msg-id 20150406135026.GJ17586@awork2.anarazel.de
Whole thread Raw
In response to BUG #12910: Memory leak with logical decoding  (pet.slavov@gmail.com)
Responses Re: BUG #12910: Memory leak with logical decoding  (Peter Slavov <pet.slavov@gmail.com>)
Re: BUG #12910: Memory leak with logical decoding  (Peter Slavov <pet.slavov@gmail.com>)
List pgsql-bugs
Hi,

I'm on holidays right now, so my answers will be delayed.

On 2015-04-06 15:35:19 +0300, Peter Slavov wrote:
> Before I start I can see that the pg_xlog directory is 7.2 GB size.
> This give me some idea that  the size of the changes cannot be much bigger
> than that.

There's no such easy correlation. That said, there pretty much never
should be a case where so much memory is needed.

> After I start ti get the transactions changes one by one with select * from
> pg_logical_slot_get_changes('<slot name>', null, 1),

As I said before, it's *not* a good idea to consume transactions
one-by-one. The startup of the decoding machinery is quite expensive. If
you want more control about how much data you get you should use the
streaming interface.

> Maybe I am not understanding something, but is this normal?

It's definitely not normal. It's unfortunately also hard to diagnose
based on the information so far. Any chance you can build a reproducible
test case?

Greetings,

Andres Freund

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: PQexec() hangs on OOM
Next
From: gcp@sjeng.org
Date:
Subject: BUG #12963: WHERE constraints on (INNER) JOIN columns are not propagated to both tables