Subject: Re: How to debug logical replication error "columns are missing" if
 they are not
To: "pgsql-admin@lists.postgresql.org" <pgsql-admin@lists.postgresql.org>
References: <6d2d142f-58b4-d2db-b271-700182b68b55@gmx.net>
 <86ce53d9-5b46-d652-78d4-2bdac368a6b0@gmx.net>
 <3219941598335790@iva8-c4b4179e2e3a.qloud-c.yandex.net>
From: Thomas Kellerer <shammat@gmx.net>
Message-ID: <ceb2b879-2f4f-2582-af02-c04d031a2fb7@gmx.net>
Date: Tue, 25 Aug 2020 10:09:15 +0200
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23)
 Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
In-Reply-To: <3219941598335790@iva8-c4b4179e2e3a.qloud-c.yandex.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Samed YILDIRIM schrieb am 25.08.2020 um 08:09:
> 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.

The change involved dropping two columns and adding a new one.
But the dropped columns were already present on the subscriber

The change essentially merged two date columns into a single daterange col=
umn.

So what would have been the correct approach here then?

1. Adding the new column on the subscriber
2. Let replication catch up
3. then drop the old columns on the subscriber

Regards
Thomas