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