Re: Logical replication disabled, recovery not possible because of 1 large transaction with schema changes?

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(at)kleczek(dot)org> wrote:

>
>
> > On 17 Oct 2024, at 11:07, Koen De Groote <kdg(dot)dev(at)gmail(dot)com> 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ł
>
>