Re: [BUGS] BUG #14785: Logical replication does not work afteradding a column. Bug? - Mailing list pgsql-bugs

From Andres Freund
Subject Re: [BUGS] BUG #14785: Logical replication does not work afteradding a column. Bug?
Date
Msg-id 20170925191655.xcn3tsnuibep3jro@alap3.anarazel.de
Whole thread Raw
In response to Re: [BUGS] BUG #14785: Logical replication does not work after addinga column. Bug?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [BUGS] BUG #14785: Logical replication does not work after addinga column. Bug?
List pgsql-bugs
Hi,

On 2017-09-13 09:46:43 -0400, Peter Eisentraut wrote:
> The prevent this problem, we filter out any tables that match this
> naming pattern and match an actual table from FOR ALL TABLES
> publications.  This is only a heuristic, meaning that user tables that
> match that naming could accidentally be omitted.  A more robust solution
> might require an explicit marking of such tables in pg_class somehow.

Yes, I think that makes sense.

> +            /*
> +             * Skip tables that look like they are from a heap rewrite (see
> +             * make_new_heap()).  We need to skip them because the subscriber
> +             * won't have a table by that name to receive the data.  That
> +             * means we won't ship the new data in, say, an added column with
> +             * a DEFAULT, but if the user applies the same DDL manually on the
> +             * subscriber, then this will work out for them.
> +             *
> +             * We only need to consider the alltables case, because such a
> +             * transient heap won't be an explicit member of a publication.
> +             */
> +            if (pub->alltables)
> +            {
> +                char       *relname = get_rel_name(relid);
> +                unsigned int u;
> +
> +                if (sscanf(relname, "pg_temp_%u", &u) == 1)
> +                {
> +                    if (get_rel_relkind(u) == RELKIND_RELATION)
> +                        break;
> +                }
> +            }
> +

This'll accept tablenames like pg_temp_1foo, right? Might be worth
being a bit narrower in the test.

Greetings,

Andres Freund


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

pgsql-bugs by date:

Previous
From: Sebastian Gröbler
Date:
Subject: Re: [BUGS] Segmentation fault mayhem
Next
From: Tomas Vondra
Date:
Subject: [BUGS] Re: Query planner skipping index depending on DISTINCT parameterorder (2)