Re: Assertion failure in SnapBuildInitialSnapshot()

On Thu, Nov 6, 2025 at 8:05 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Nov 7, 2025 at 8:30 AM Zhijie Hou (Fujitsu)
> <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> >
> > On Friday, November 7, 2025 2:36 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > On Thu, Nov 6, 2025 at 2:36 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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