]> granicus.if.org Git - postgresql/commit
Fix memory leak in TRUNCATE decoding
authorTomas Vondra <tomas.vondra@postgresql.org>
Mon, 3 Sep 2018 00:10:24 +0000 (02:10 +0200)
committerTomas Vondra <tomas.vondra@postgresql.org>
Mon, 3 Sep 2018 00:10:24 +0000 (02:10 +0200)
commit4ddd8f5f55a0a1967fc787e42182745ca1e3a995
tree52683b5b9189d59c91e914b586dfc8511257c13e
parentcaa0c6ceba1fd6ec7b027532d68cecf5dfbbb2db
Fix memory leak in TRUNCATE decoding

When decoding a TRUNCATE record, the relids array was being allocated in
the main ReorderBuffer memory context, but not released with the change
resulting in a memory leak.

The array was also ignored when serializing/deserializing the change,
assuming all the information is stored in the change itself.  So when
spilling the change to disk, we've only we have serialized only the
pointer to the relids array.  Thanks to never releasing the array,
the pointer however remained valid even after loading the change back
to memory, preventing an actual crash.

This fixes both the memory leak and (de)serialization.  The relids array
is still allocated in the main ReorderBuffer memory context (none of the
existing ones seems like a good match, and adding an extra context seems
like an overkill).  The allocation is wrapped in a new ReorderBuffer API
functions, to keep the details within reorderbuffer.c, just like the
other ReorderBufferGet methods do.

Author: Tomas Vondra
Discussion: https://www.postgresql.org/message-id/flat/66175a41-9342-2845-652f-1bd4c3ee50aa%402ndquadrant.com
Backpatch: 11, where decoding of TRUNCATE was introduced
src/backend/replication/logical/decode.c
src/backend/replication/logical/reorderbuffer.c
src/include/replication/reorderbuffer.h