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

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

Thanks for the answer, and happy holidays


На 6.04.2015 в 16:50, Andres Freund написа:
> 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.
I tried with more transactions or without limit there but there is no
difference.
I actually tried before with pg_recvlogical, which is actually using the
streaming interface,
but the result was exactly the same. My guess is that the problem is in
the plug-in actualy..
>> 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?
Yes I will try to make a test case that is reproducible.
>
> Greetings,
>
> Andres Freund

Thanks,
Peter Slavov

pgsql-bugs by date:

Previous
From: Christian Almeida
Date:
Subject: Re: BUG #12989: pg_size_pretty with negative values
Next
From: "David G. Johnston"
Date:
Subject: Re: BUG #12989: pg_size_pretty with negative values