Re: BUG #12910: Memory leak with logical decoding

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: BUG #12910: Memory leak with logical decoding
Дата
Msg-id 20150331144048.GL4878@alap3.anarazel.de
обсуждение исходный текст
Ответ на BUG #12910: Memory leak with logical decoding  (pet.slavov@gmail.com)
Ответы 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>)
Re: BUG #12910: Memory leak with logical decoding  (Peter Slavov <pet.slavov@gmail.com>)
Список pgsql-bugs
Hi,

On 2015-03-27 09:47:57 +0000, pet.slavov@gmail.com wrote:
> I am trying to use logical decoding to replay the data modifying queries on
> a different server, to synchronize some of the tables. The primary server
> has some load, but not so much. I am getting the changes with
> pg_logical_slot_get_changes limiting the changes to 50 at a time.

That's generally not a very good idea. It's much better to use the
streaming interface. Repeatedly starting/stopping a logical slot (as the
SQL interface has to do every time) isn't all that efficient.

> At some point pg_logical_slot_get_changes queries become slow and starts to
> eat all the ram and swap, which eventually kills the primary database with
> this error:
>  FATAL:  the database system is in recovery mode.

That indicates a crash. Please check the server log for any details?  If
it crashes, could you perhaps get a backtrace?

What output plugin are you using?

> The nature of changes on the primary can have a lot of data in one
> transaction. Which I guess is the reason of the slow
> pg_logical_slot_get_changes.

In that case changes should just be spooled to disk.

Greetings,

Andres Freund

В списке pgsql-bugs по дате отправления:

Предыдущее
От: pet.slavov@gmail.com
Дата:
Сообщение: BUG #12910: Memory leak with logical decoding
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: BUG #12908: tstzrange constructor fails when used in WHERE clause