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 20170823213949.g7wpurzt6hbi3e5h@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
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


-- 
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: Peter Eisentraut
Date:
Subject: Re: [BUGS] BUG #14785: Logical replication does not work after addinga column. Bug?
Next
From: Masahiko Sawada
Date:
Subject: Re: [BUGS] BUG #14788: `pg_restore -c` won't restore schema access privileges.