MIME-Version: 1.0
References: <ZgQeJDcxB9zYJKIt@ip-10-97-1-34.eu-west-3.compute.internal>
 <CALj2ACX1bdaX2gf5ttwk3buiDrgZVV=vM6S1SQKf=Sxhj1HkzQ@mail.gmail.com>
 <CAA4eK1JU14-Fz3Ttx_wy=vzDaeTSv=umt7sC3N+4k2aYcdk4=w@mail.gmail.com>
 <CALj2ACWOz0tEY2vi3OneittGj9+yrQ9A6+6YYb1Cj7L_QrdMVg@mail.gmail.com>
 <CAD21AoAd0BX0L17YxSCbSNbj=3V7dvLVGY0WhwLHAt724rNCZA@mail.gmail.com>
 <ZgulmKzdqxuBuhCU@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAJpy0uBthb-RG=Xg+mM-G6Xy01JLcBsizJuz+xbti08qP_W7AQ@mail.gmail.com>
 <CALj2ACVfDBcbybgyga7ia_KiQPAfEi_3=VDOGf2VU8RkJZSQpw@mail.gmail.com>
 <Zg0QgarM9UlRutLw@ip-10-97-1-34.eu-west-3.compute.internal>
 <CALj2ACUmp-F+irHYfNhmo_9yaCo7aGi7ZB20KQcDR3S9eT56hg@mail.gmail.com>
 <Zg1WqRS/gQrLG2vl@ip-10-97-1-34.eu-west-3.compute.internal>
 <CALj2ACUBiRLHF7VYD-0nYVHSvVBSCQ_5OMbP4tE8Ys_rpvQ--A@mail.gmail.com>
 <CAD21AoATS=8+izerKERjoNCrakk+cw=YvtvUsgiVcNE1GENLog@mail.gmail.com>
 <CALj2ACVFhnCq3oPREE0i24mPArCjqbvtbF9QDJyw+NuiAZOoiA@mail.gmail.com>
 <CAD21AoBF_XjJqNV8bf838fpZHR==ANsP98tFF4Ei1VKKLYxZQw@mail.gmail.com> <CAA4eK1J99e0vHGcL=3Nf9vxDhOA1u=h5kL_=EUW_ztTPttir4w@mail.gmail.com>
In-Reply-To: <CAA4eK1J99e0vHGcL=3Nf9vxDhOA1u=h5kL_=EUW_ztTPttir4w@mail.gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Thu, 4 Apr 2024 18:05:02 +0900
Message-ID: <CAD21AoAurWk4-Jk8Dne_kXDGF8FGUTLUZ0t2jxGoDgAehHYD_w@mail.gmail.com>
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, 
	Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, shveta malik <shveta.malik@gmail.com>, 
	Nathan Bossart <nathandbossart@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAD21AoAurWk4-Jk8Dne_kXDGF8FGUTLUZ0t2jxGoDgAehHYD_w%40mail.gmail.com>
Precedence: bulk

On Thu, Apr 4, 2024 at 5:36=E2=80=AFPM Amit Kapila <amit.kapila16@gmail.com=
> wrote:
>
> On Thu, Apr 4, 2024 at 1:32=E2=80=AFPM Masahiko Sawada <sawada.mshk@gmail=
.com> wrote:
> >
> > On Thu, Apr 4, 2024 at 1:34=E2=80=AFPM Bharath Rupireddy
> > <bharath.rupireddyforpostgres@gmail.com> wrote:
> > >
> > > On Thu, Apr 4, 2024 at 9:42=E2=80=AFAM Masahiko Sawada <sawada.mshk@g=
mail.com> wrote:
> > > >
> > > > @@ -1368,6 +1416,7 @@ ShutDownSlotSync(void)
> > > >     if (SlotSyncCtx->pid =3D=3D InvalidPid)
> > > >     {
> > > >         SpinLockRelease(&SlotSyncCtx->mutex);
> > > > +       update_synced_slots_inactive_since();
> > > >         return;
> > > >     }
> > > >     SpinLockRelease(&SlotSyncCtx->mutex);
> > > > @@ -1400,6 +1449,8 @@ ShutDownSlotSync(void)
> > > >     }
> > > >
> > > >     SpinLockRelease(&SlotSyncCtx->mutex);
> > > > +
> > > > +   update_synced_slots_inactive_since();
> > > >  }
> > > >
> > > > Why do we want to update all synced slots' inactive_since values at
> > > > shutdown in spite of updating the value every time when releasing t=
he
> > > > slot? It seems to contradict the fact that inactive_since is update=
d
> > > > when releasing or restoring the slot.
> > >
> > > It is to get the inactive_since right for the cases where the standby
> > > is promoted without a restart similar to when a standby is promoted
> > > with restart in which case the inactive_since is set to current time
> > > in RestoreSlotFromDisk.
> > >
> > > Imagine the slot is synced last time at time t1 and then a few hours
> > > passed, the standby is promoted without a restart. If we don't set
> > > inactive_since to current time in this case in ShutDownSlotSync, the
> > > inactive timeout invalidation mechanism can kick in immediately.
> > >
> >
> > Thank you for the explanation! I understood the needs.
> >
>
> Do you want to review the v34_0001* further or shall I proceed with
> the commit of the same?

Thanks for asking. The v34-0001 patch looks good to me.

Regards,

--=20
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com