Re: [BUGS] BUG #14785: Logical replication does not work afteradding a column. Bug?
От | Andres Freund |
---|---|
Тема | Re: [BUGS] BUG #14785: Logical replication does not work afteradding a column. Bug? |
Дата | |
Msg-id | 20170823163151.5dankkw7z72ltmvw@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14785: Logical replication does not work after addinga column. Bug? (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [BUGS] BUG #14785: Logical replication does not work after addinga column. Bug?
|
Список | 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 -- 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 по дате отправления: