Re: pg_upgrade and publication/subscription problem

From: Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade and publication/subscription problem
Date: 2021-11-29 11:34:48
Message-ID: CAB-JLwZg8ysfmGbVvjWYhUqEOYmEvO8Aok3UMFj=t+rssGhtfg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> On thinking about this point again, it is not clear to me why that
> would matter for this particular use case? Basically, when you create
> a new subscription, it should copy the entire existing data from the
> table directly and then will decode changes from WAL. So, I think in
> your case all the changes between pg_upgrade and now should be
> directly copied from tables, so probably older WAL won't be required.
>

Maybe you did not understand
Production server cannot stop while I upgrade my subscriber server, so it
will be creating WAL continuously.

Subscriber server has trigger functions for auditing on all tables,
something like ...
insert into auditable(schemaname, tablename, primarykey, operation,
olddata, newdata) values(tg_table_schema, tg_table_name, getpk(new), tg_op,
row_to_json(old), row_to_json(new))

Then, all changes between pg_upgrade and now will not be inserted into
auditable.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marcos Pegoraro 2021-11-29 12:03:06 Re: Commitfest 2021-11 Patch Triage - Part 1
Previous Message Amit Kapila 2021-11-29 11:17:46 Re: row filtering for logical replication