Re: handling of heap rewrites in logical decoding

On 25 February 2018 at 09:57, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> A heap rewrite during a DDL command publishes changes for relations
> named like pg_temp_%u, which are not real tables, and this breaks
> replication systems that are not aware of that. We have a hack in the
> pgoutput plugin to ignore those, but we knew that was a hack. So here
> is an attempt at a more proper solution: Store a relisrewrite column in
> pg_class and filter on that.
>
> I have put this into reorderbuffer.c, so that it affects all plugins.
> An alternative would be to have each plugin handle it separately (the
> way it is done now), but it's hard to see why a plugin would not want
> this fixed behavior.
>

>
> A more fancy solution would be to make this column an OID that links
> back to the original table. Then, a DDL-aware plugin could choose
> replicate the rewrite rows. However, at the moment no plugin works that
> way, so this might be overdoing it.
>

I'm pretty sure we _will_ want the ability to decode and stream rewrite
contents for non-IMMUTABLE table rewrites.

Filtering out by default is OK by me, but I think making it impossible to
decode is a mistake. So I'm all for the oid option and had written a
suggestion for it before I saw you already mentioned it in the next part
of your mail.

The main issue with filtering out rewrites by default is that I don't see
how, if we default to ignore/filter-out, plugins would indicate "actually I
want to choose about this one" or "I understand table rewrites". I'd prefer
not to add another change callback.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services