On Mon, Mar 4, 2024 at 3:14 AM Nathan Bossart <nathandboss...@gmail.com> wrote: > > On Sun, Mar 03, 2024 at 11:40:00PM +0530, Bharath Rupireddy wrote: > > On Sat, Mar 2, 2024 at 3:41 AM Nathan Bossart <nathandboss...@gmail.com> > > wrote: > >> Would you ever see "conflict" as false and "invalidation_reason" as > >> non-null for a logical slot? > > > > No. Because both conflict and invalidation_reason are decided based on > > the invalidation reason i.e. value of slot_contents.data.invalidated. > > IOW, a logical slot that reports conflict as true must have been > > invalidated. > > > > Do you have any thoughts on reverting 007693f and introducing > > invalidation_reason? > > Unless I am misinterpreting some details, ISTM we could rename this column > to invalidation_reason and use it for both logical and physical slots. I'm > not seeing a strong need for another column. Perhaps I am missing > something... >
IIUC, the current conflict_reason is primarily used to determine logical slots on standby that got invalidated due to recovery time conflict. On the primary, it will also show logical slots that got invalidated due to the corresponding WAL got removed. Is that understanding correct? If so, we are already sort of overloading this column. However, now adding more invalidation reasons that won't happen during recovery conflict handling will change entirely the purpose (as per the name we use) of this variable. I think invalidation_reason could depict this column correctly but OTOH I guess it would lose its original meaning/purpose. -- With Regards, Amit Kapila.
