Re: BUG #14785: Logical replication does not work after adding a column. Bug?

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

In response to

Responses

Browse pgsql-bugs by date

  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.