Re: Assertion failure in SnapBuildInitialSnapshot()
| От | Amit Kapila |
|---|---|
| Тема | Re: Assertion failure in SnapBuildInitialSnapshot() |
| Дата | |
| Msg-id | CAA4eK1L+Avbp46_VPd1tBW8vex_NuZtCWxgD_4cgvBaxtPkPWQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | RE: Assertion failure in SnapBuildInitialSnapshot() ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
| Ответы |
Re: Assertion failure in SnapBuildInitialSnapshot()
|
| Список | pgsql-hackers |
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. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: