Re: How to debug logical replication error "columns are missing" if they are not - Mailing list pgsql-admin

From Thomas Kellerer
Subject Re: How to debug logical replication error "columns are missing" if they are not
Date
Msg-id 86ce53d9-5b46-d652-78d4-2bdac368a6b0@gmx.net
Whole thread Raw
In response to How to debug logical replication error "columns are missing" if they are not  (Thomas Kellerer <shammat@gmx.net>)
List pgsql-admin
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
replicatedany more. 
Is it possible that the error message mentions an unrelated table?

How can I find out which table really causes the problem?

Thomas




pgsql-admin by date:

Previous
From: Thomas Kellerer
Date:
Subject: How to debug logical replication error "columns are missing" if they are not
Next
From: Thomas Kellerer
Date:
Subject: Re: How to debug logical replication error "columns are missing" if they are not