Re: memory leak when serializing TRUNCATE in reorderbuffer

2018-09-02 Thread Tomas Vondra
I've pushed this, with some minor tweak, and backpatched to 11 (which is where TRUNCATE decoding was introduced). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: memory leak when serializing TRUNCATE in reorderbuffer

2018-08-16 Thread Tomas Vondra
On 08/08/2018 09:47 PM, Tomas Vondra wrote: > > IMHO the cleanest way is to add a method like > ReorderBufferGetChange, which does the allocation internally. That > way the memory context choice is up to reorderbuffer, not decode.c. > That's at least consistent with what the rest of decode.c

Re: memory leak when serializing TRUNCATE in reorderbuffer

2018-08-08 Thread Tomas Vondra
On 08/08/2018 09:19 PM, Peter Eisentraut wrote: On 20/06/2018 21:42, Tomas Vondra wrote: So I think we should fix and serialize/restore the OID array, just like we do for tuples, snapshots etc. See the attached fix. Yes please. OK, will do. Another thing we should probably reconsider

Re: memory leak when serializing TRUNCATE in reorderbuffer

2018-08-08 Thread Peter Eisentraut
On 20/06/2018 21:42, Tomas Vondra wrote: > So I think we should fix and serialize/restore the OID array, just like > we do for tuples, snapshots etc. See the attached fix. Yes please. > Another thing we should probably reconsider is where the relids is > allocated - the pointer remains valid

memory leak when serializing TRUNCATE in reorderbuffer

2018-06-20 Thread Tomas Vondra
Hi, While rebasing the logical replication patches on top of PG11, I've noticed that ReorderBufferSerializeChange claims this: case REORDER_BUFFER_CHANGE_TRUNCATE: ... /* ReorderBufferChange contains everything important */ That is not quite correct, though - the OIDs of