On Thu, Nov 6, 2025 at 8:05 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Nov 7, 2025 at 8:30 AM Zhijie Hou (Fujitsu)
> <houzj.fnst@fujitsu.com> wrote:
> >
> > On Friday, November 7, 2025 2:36 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > > On Thu, Nov 6, 2025 at 2:36 AM Amit Kapila <amit.kapila16@gmail.com>
> > > wrote:
> > > >
> > > > Good point. This can happen when the last slot is invalidated or dropped.
> > >
> > > After the last slot is invalidated or dropped, both slot_xmin and
> > > slot_catalog_xmin values are set InvalidTransactionId. Then in this
> > > case, these values are ignored when computing the oldest safe decoding
> > > XID in GetOldestSafeDecodingTransactionId(), no? Or do you mean that
> > > there is a case where slot_xmin and slot_catalog_xmin retreat to a
> > > valid XID?
> >
> > I think when replication_slot_xmin is invalid,
> > GetOldestSafeDecodingTransactionId would return nextXid, which can be greater
> > than the original snap.xmin if some transaction IDs have been assigned.
> >
>
> Won't we have a problem that values of
> procArray->replication_slot_xmin and
> procArray->replication_slot_catalog_xmin won't be set to
> InvalidTransactionId after last slot removal due to a new check unless
> we do special treatment for drop/invalidation of a slot? And that
> would lead to accumulating dead rows even when not required.
I understand Hou-san's point. Agreed. procArray->replication_slot_xmin
and replication_slot_catalog_xmin should not retreat to a valid XID
but could become 0 (invalid). Let's consider the idea of inverting the
locks as Andres proposed[1].
Regards,
[1] https://www.postgresql.org/message-id/20230207194903.ws4acm7ake6ikacn%40awork3.anarazel.de
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
