On Fri, Aug 11, 2023 at 10:43 AM Julien Rouhaud <rjuju123@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.kapila16@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.