On 25 February 2018 at 09:57, Peter Eisentraut < peter.eisentr...@2ndquadrant.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
