Re: Memory leak in XLOG reader facility when decoding records (caused by WAL refactoring)
От | Heikki Linnakangas |
---|---|
Тема | Re: Memory leak in XLOG reader facility when decoding records (caused by WAL refactoring) |
Дата | |
Msg-id | 55B71D16.3060600@iki.fi обсуждение исходный текст |
Ответ на | Re: Memory leak in XLOG reader facility when decoding records (caused by WAL refactoring) (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Memory leak in XLOG reader facility when decoding records
(caused by WAL refactoring)
|
Список | pgsql-bugs |
On 07/28/2015 02:54 AM, Michael Paquier wrote: > On Tue, Jul 28, 2015 at 2:32 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: >> Thanks, committed. The leak was not actually in the "main_data" handling, as >> quoted in the above snippet, but in the per-block buffers. > > The patch pushed does not take care of the leak (tested on 3d5cb31c). > With the test script I sent upthread, I am still seeing it: > ==32015== 154 bytes in 1 blocks are definitely lost in loss record 103 of 155 > ==32015== at 0x6B1B: malloc (in > /usr/local/Cellar/valgrind/3.10.1/lib/valgrind/vgpreload_memcheck-amd64-darwin.so) > ==32015== by 0x10000DB2D: pg_malloc_internal (fe_memutils.c:30) > ==32015== by 0x10000DE79: palloc (fe_memutils.c:118) > ==32015== by 0x100005270: DecodeXLogRecord (xlogreader.c:1200) > ==32015== by 0x100003A79: XLogReadRecord (xlogreader.c:458) > ==32015== by 0x100002AF0: findLastCheckpoint (parsexlog.c:186) > ==32015== by 0x1000017E1: main (pg_rewind.c:257) > ==32015== > ==32015== 154 bytes in 1 blocks are definitely lost in loss record 104 of 155 > ==32015== at 0x6B1B: malloc (in > /usr/local/Cellar/valgrind/3.10.1/lib/valgrind/vgpreload_memcheck-amd64-darwin.so) > ==32015== by 0x10000DB2D: pg_malloc_internal (fe_memutils.c:30) > ==32015== by 0x10000DE79: palloc (fe_memutils.c:118) > ==32015== by 0x100005270: DecodeXLogRecord (xlogreader.c:1200) > ==32015== by 0x100003A79: XLogReadRecord (xlogreader.c:458) > ==32015== by 0x1000022E0: extractPageMap (parsexlog.c:78) > ==32015== by 0x10000187C: main (pg_rewind.c:280) > > The problem is that state->max_block_id gets reset to -1 each time a > new record is read via ResetDecoder. Hence if we decode a record that > has block data and then if a second record that does not contain block > data is decoded, we will leak if XLogReaderFree is called because no > attempts will be made to pfree what has been allocated. Per se the > patch attached. Ok, committed. I hope we got it right this time.. - Heikki
В списке pgsql-bugs по дате отправления: