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 |
Date: | 2023-04-24 06:50:32 |
Message-ID: | 20230424065032.4w7vm33qmaput3al@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Fri, Apr 14, 2023 at 04:19:35AM +0000, Hayato Kuroda (Fujitsu) wrote:
>
> I have tested, but srsublsn became NULL if copy_data was specified as off.
> This is because when copy_data is false, all tuples in pg_subscription_rels are filled
> as state = 'r' and srsublsn = NULL, and tablesync workers will never boot.
> See CreateSubscription().
> Doesn't it mean that there is a possibility that LSN option is not specified while
> ALTER SUBSCRIPTION ADD TABLE?
It shouldn't be the case for now, as pg_upgrade will check first if there's a
invalid remote_lsn and refuse to proceed if that's the case. Also, the
remote_lsn should be set as soon as some data is replicated, so unless you add
a table that's never modified to a publication you should be able to run
pg_upgrade at some point, once there's replicated DML on such a table.
I'm personally fine with the current restrictions, but I don't really use
logical replication in any project so maybe I'm not objective enough. For now
I'd rather keep things as-is, and later improve on it if some people want to
lift such restrictions (and such restrictions can actually be lifted).
From | Date | Subject | |
---|---|---|---|
Next Message | Drouvot, Bertrand | 2023-04-24 07:03:53 | Re: Autogenerate some wait events code and documentation |
Previous Message | Masahiko Sawada | 2023-04-24 06:42:56 | Re: Perform streaming logical transactions by background workers and parallel apply |