Hi Thomas,
Have you dropped any column during or after main schema changes?
If yes, you should add columns you dropped on publisher side to subscriber side. These two tables can be identical now. But, if you added a column to publisher, and then dropped it, and you never added the column(s) on subscriber side, you would get error. Because, you are looking current status of tables, but logs that should be consumed and data that should be replicated belong to past.
Best regards.
Samed YILDIRIM
08:52, 25 August 2020, Thomas Kellerer <shammat@xxxxxxx>:
Thomas Kellerer schrieb am 25.08.2020 um 07:32:
we have a a logical replication from Postgres 11 to Postgres 12.
We did some structural changes to the published tables. The changes
to the subscriber where applied about 60 minutes later then those on
the publisher. Obviously before the subscriber's tables where synced
the replication failed.
But even though the tables are now completely identical, the subscriber still claims:
logical replication target relation "public.employee" is missing some replicated columns
I double checked multiple times that the tables are now identical by
doing a diff of the "pg_dump -s" outputs - they are identical in the
CREATE TABLE part.
The table is listed with state "r" (ready) in pg_subscription_rel
How can I find out which columns it thinks are missing? And how do I
convince the subscriber that the tables *are* identical?
This is getting stranger:
I dropped the table from the publication.
After refreshing the subscription the error is still shown in the logfile even though that table shouldn't be replicated any more.
Is it possible that the error message mentions an unrelated table?
How can I find out which table really causes the problem?
Thomas
