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
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? |