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 21:39:49
Message-ID: 20170823213949.g7wpurzt6hbi3e5h@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2017-08-23 17:35:11 -0400, Peter Eisentraut wrote:
> On 8/23/17 12:31, Andres Freund wrote:
> > This is "known" behaviour - this is the actual data WAL logged :(. Table
> > rewrites generate these pg_temp* tables and log the data there...
>
> Hmm, I see.
>
> Possibly, one way a user could recover from this is to add the column on
> the subscriber, rename to table on the subscriber to the temp name, then
> wait until all the changes from the rewrite are applied, at which point
> it should start complaining in the logs that the original table name
> does not exist, then rename the table back.

I think we could actually kind of solve this by just ignoring pg_temp*
tables in the output plugin. Given we don't do DDL replication at this
point, that seems good enough. "all" we need is a way to make sure we're
not confusing the pg_temp* tables with a table the user has declared as
pg_temp - but we could check subscription state for that?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Masahiko Sawada 2017-08-24 03:29:17 Re: BUG #14788: `pg_restore -c` won't restore schema access privileges.
Previous Message Peter Eisentraut 2017-08-23 21:35:11 Re: BUG #14785: Logical replication does not work after adding a column. Bug?