|From:||Julien Rouhaud <rjuju123(at)gmail(dot)com>|
|To:||"Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>|
|Cc:||PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>|
|Subject:||Re: pg_upgrade and logical replication|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Thu, Apr 06, 2023 at 04:49:59AM +0000, Hayato Kuroda (Fujitsu) wrote:
> Dear Julien,
> > I'm attaching a v3 to fix a recent conflict with pg_dump due to a563c24c9574b7
> > (Allow pg_dump to include/exclude child tables automatically).
> Thank you for making the patch.
> FYI - it could not be applied due to recent commits. SUBOPT_* and attributes
> in SubscriptionInfo was added these days.
Thanks a lot for warning me!
While rebasing and testing the patch, I realized that I forgot to git-add a
chunk, so I want ahead and added some minimal TAP tests to make sure that the
feature and various checks work as expected, also demonstrating that you can
safely resume after running pg_upgrade a logical replication setup where only
some of the tables are added to a publication, where new rows and new tables
are added to the publication while pg_upgrade is running (for the new table you
obviously need to make sure that the same relation exist on the subscriber side
but that's orthogonal to this patch).
While doing so, I also realized that the subscription's underlying replication
origin remote LSN is only set after some activity is seen *after* the initial
sync, so I also added a new check in pg_upgrade to make sure that all remote
origin tied to a subscription have a valid remote_lsn when the new option is
used. Documentation is updated to cover that, same for the TAP tests.
|Next Message||Julien Rouhaud||2023-04-07 02:48:23||Re: [PoC] pg_upgrade: allow to upgrade publisher node|
|Previous Message||Andres Freund||2023-04-07 02:18:30||Re: Minimal logical decoding on standbys|