Re: pg_upgrade and logical replication
От | Julien Rouhaud |
---|---|
Тема | Re: pg_upgrade and logical replication |
Дата | |
Msg-id | 20230407022802.jqmdhgjhrnj5lpcl@jrouhaud обсуждение исходный текст |
Ответ на | RE: pg_upgrade and logical replication ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
RE: pg_upgrade and logical replication
Re: pg_upgrade and logical replication Re: pg_upgrade and logical replication RE: pg_upgrade and logical replication |
Список | pgsql-hackers |
Hi, 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. v4 attached.
Вложения
В списке pgsql-hackers по дате отправления: