From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | yxq(at)o2(dot)pl, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14785: Logical replication does not work after adding a column. Bug? |
Date: | 2017-08-23 16:31:51 |
Message-ID: | 20170823163151.5dankkw7z72ltmvw@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2017-08-23 09:25:13 -0400, Peter Eisentraut wrote:
> On 8/22/17 15:34, Andres Freund wrote:
> > On 2017-08-22 15:22:41 -0400, Peter Eisentraut wrote:
> >> When you add a column on the publication side, you also need to add it
> >> on the subscription side, otherwise there is nowhere to put the data.
> >
> > Op's sql shows that that's done. The problem is the table rewrite not
> > being handled nicely by logical decoding / replication.
>
> OK, I see it now.
>
> The problem happens on the publisher side. After the table rewrite on
> the publisher side, the output plugin starts sending the wrong relname.
>
> The name comes straight from RelationGetRelationName() (in
> logicalrep_write_rel()) with the Relation that gets passed into the
> pgoutput_change() callback, so there doesn't appear to be an obvious
> logic error in the output plugin.
>
> Any ideas? Do we need to renew a snapshot somehow, perhaps?
This is "known" behaviour - this is the actual data WAL logged :(. Table
rewrites generate these pg_temp* tables and log the data there...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-08-23 21:35:11 | Re: BUG #14785: Logical replication does not work after adding a column. Bug? |
Previous Message | Fujimoto Seiji | 2017-08-23 14:00:58 | Re: BUG #14788: `pg_restore -c` won't restore schema access privileges. |