On Thu, Aug 10, 2023 at 2:27 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Aug 7, 2023 at 3:46 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Mon, Aug 7, 2023 at 1:06 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
> > >
> > > On Mon, Aug 07, 2023 at 12:42:33PM +0530, Amit Kapila wrote:
> > > > On Mon, Aug 7, 2023 at 11:29 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> > > > >
> > > > > Unless I'm missing something I don't see what prevents something to connect
> > > > > using the replication protocol and issue any query or even create new
> > > > > replication slots?
> > > > >
> > > >
> > > > I think the point is that if we have any slots where we have not
> > > > consumed the pending WAL (other than the expected like
> > > > SHUTDOWN_CHECKPOINT) or if there are invalid slots then the upgrade
> > > > won't proceed and we will request user to remove such slots or ensure
> > > > that WAL is consumed by slots. So, I think in the case you mentioned,
> > > > the upgrade won't succeed.
> > >
> > > What if new slots are added while the old instance is started in the middle of
> > > pg_upgrade, *after* the various checks are done?
> > >
> >
> > They won't be copied but I think that won't be any different than
> > other objects like tables. Anyway, I have another idea which is to not
> > allow creating slots during binary upgrade unless one specifically
> > requests it by having an API like binary_upgrade_allow_slot_create()
> > similar to existing APIs binary_upgrade_*.
> >
>
> 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. The same is true for other
objects, as Amit mentioned.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com