On Thu, Nov 6, 2025 at 8:05 PM Amit Kapila <[email protected]> wrote: > > On Fri, Nov 7, 2025 at 8:30 AM Zhijie Hou (Fujitsu) > <[email protected]> wrote: > > > > On Friday, November 7, 2025 2:36 AM Masahiko Sawada <[email protected]> > > wrote: > > > On Thu, Nov 6, 2025 at 2:36 AM Amit Kapila <[email protected]> > > > 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
