Hello Michał,
Thanks for the reply. I suspected as much, I was just wondering if there was an easy fix that didn't involve dropping the entire subscription and having to re-do all the table because of that. Guess my only option is to remove the affected tables from the publisher before the patch, refresh subscription, do the patch, recreate the tables on the subscriber and do the sync for only those tables.
I will look in to your suggestion.
Regards,
Koen De Groote
On Thu, Oct 17, 2024 at 11:17 AM Michał Kłeczek <michal@xxxxxxxxxxx> wrote:
> On 17 Oct 2024, at 11:07, Koen De Groote <kdg.dev@xxxxxxxxx> wrote:
>
> Hello Muhammad,
>
> The problem with my scenario is the changes are written as a single transaction, with a BEGIN and COMMIT. In that transaction, there are first inserts, then a schema change, and then inserts on the new schema.
I guess until logical replication of DDL is available you’re out of luck.
The best you can do is to have a separate table for recording and replaying schema changes.
Create triggers that perform actual DDL operations based on DML in this table.
Publish this table on the publisher in the same publication as the tables affected by the DDL.
On the subscriber side it is the same - just make the trigger is marked as ENABLE REPLICA TRIGGER or ENABLE ALWAYS TRIGGER.
Kind regards,
Michał
