From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Chad Trabant <chad(at)iris(dot)washington(dot)edu>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15044: materialized views incompatibility with logical replication in postgres 10 |
Date: | 2018-02-18 03:43:38 |
Message-ID: | 6e375316-91a4-7825-ef8b-9b8915ab6980@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 2/5/18 10:33, Petr Jelinek wrote:
>> Exactly. The matview does not show up in pg_publication_tables but it's
>> registered at some level.
>
> Indeed this is a bug. For normal publications we take care of this when
> adding the relation to the publication but since ALL TABLES publications
> don't check for membership we have to filter this directly in the output
> plugin.
I think the filtering in pgoutput ought to make use of
is_publishable_class() in some way. That takes care of non-tables such
as materialized views, but it also filters out the information_schema
tables for example. Right now, if you insert something into one of the
IS tables, it gets shipped over the wire but is then dropped by the
apply because there is no pg_subscription_rel entry of the table. That
doesn't quite have the user-visible effect as this bug, but it's bogus
nonetheless.
So I propose this alternative patch that covers all these cases.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-Fix-filtering-of-unsupported-relations-in-pgoutput.patch | text/plain | 2.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2018-02-18 09:52:23 | BUG #15072: Unable to get tablespace from pg_tables for new created table |
Previous Message | Bradley Ayers | 2018-02-17 22:54:19 | Transaction local custom settings set to '' rather than removed entirely after transaction ends |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-02-18 04:22:53 | Re: ALTER TABLE ADD COLUMN fast default |
Previous Message | David Rowley | 2018-02-18 02:25:47 | Re: [HACKERS] path toward faster partition pruning |