Re: BUG #12910: Memory leak with logical decoding
От | Peter Slavov |
---|---|
Тема | Re: BUG #12910: Memory leak with logical decoding |
Дата | |
Msg-id | 5526969F.4050704@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #12910: Memory leak with logical decoding (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #12910: Memory leak with logical decoding
|
Список | pgsql-bugs |
Hi Andres, I prepared a test case, that can reproduce the problem. This is the link to the SQL File <https://my.pcloud.com/publink/show?code=XZHuLXZomc1T6UJy3XUUJY19wHPejNjNjJk> . I am just creating few tables and filling then with data then deleting and then filling again; This will produce tables with size ~1.5 GB 2 times and delete them ones. This queries in the logical decoding of course will be one row for each inserted and deleted row. Which will produce ~ 15GB of data for one transactions. I get the data from terminal like thins: psql test_case -c "select * from pg_logical_slot_get_changes('testing', null, 1);" 1>//tmp/replay.sql You can see that when the big transaction is red from the WAL files all this 15GB is going to the RAM and swap space. Eventually if you get enough RAM and swap the data will be compiled and after that written to the file. I know that this setup is not optimal, but it can reproduce the big memory usage. Greetings, Peter Slavov Ðа 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. > >> 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 по дате отправления: