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
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 does.
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 i
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 be
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 t