Re: BUG #12910: Memory leak with logical decoding
От | Peter Slavov |
---|---|
Тема | Re: BUG #12910: Memory leak with logical decoding |
Дата | |
Msg-id | 55229E70.3040305@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #12910: Memory leak with logical decoding (Andres Freund <andres@anarazel.de>) |
Список | 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 по дате отправления: