On Fri, Aug 11, 2023 at 10:43 AM Julien Rouhaud <rjuju...@gmail.com> wrote: > > On Thu, Aug 10, 2023 at 04:30:40PM +0900, Masahiko Sawada wrote: > > On Thu, Aug 10, 2023 at 2:27 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > Sawada-San, Julien, and others, do you have any thoughts on the above > > > point? > > > > IIUC during the old cluster running in the middle of pg_upgrade it > > doesn't accept TCP connections. I'm not sure we need to worry about > > the case where someone in the same server attempts to create > > replication slots during the upgrade. > > AFAICS this is only true for non-Windows platform, so we would still need some > extra safeguards on Windows. Having those on all platforms will probably be > simpler and won't hurt otherwise. > > > The same is true for other objects, as Amit mentioned. > > I disagree. As I mentioned before any module registered in > shared_preload_libraries can spawn background workers which can perform any > activity. There were previous reports of corruption because of multi-xact > being generated by such bgworkers during pg_upgrade, I'm pretty sure that > there > are some modules that create objects (automatic partitioning tools for > instance). It's also unclear to me what would happen if some writes are > performed by such module at various points of the pg_upgrade process. > Couldn't > that lead to either data loss or broken slot (as it couldn't stream changes > from older major version)? >
It won't be any bad than what can happen to tables. If we know that such bgworkers can cause corruption if they do writes during the upgrade, I don't think it is the job of this patch to prevent the related scenarios. We can probably disallow the creation of new slots during the binary upgrade but that also I am not sure. I guess it would be better to document such hazards as a first step and then probably write a patch to prevent WAL writes or something along those lines. -- With Regards, Amit Kapila.
