On Fri, Feb 28, 2025 at 9:45 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Feb 28, 2025 at 6:15 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > > On Thu, Feb 27, 2025 at 12:14 AM Zhijie Hou (Fujitsu) > > > > > > I think distributing invalidations to a transaction that has not yet > > > built a > > > base snapshot is un-necessary. This is because, during the process of > > > building > > > its base snapshot, such a transaction will have already recorded the XID > > > of the > > > transaction that altered the publication information into its array of > > > committed XIDs. Consequently, it will reflect the latest changes in the > > > catalog > > > from the beginning. In the context of logical decoding, this scenario is > > > analogous to decoding a new transaction initiated after the catalog-change > > > transaction has been committed. > > > > > > The original issue arises because the catalog cache was constructed using > > > an > > > outdated snapshot that could not reflect the latest catalog changes. > > > However, > > > this is not a problem in cases without a base snapshot. Since the existing > > > catalog cache should have been invalidated upon decoding the committed > > > catalog-change transaction, the subsequent transactions will construct a > > > new > > > cache with the latest snapshot. > > > > I've also concluded it's not necessary but the reason and analysis > > might be somewhat different. >
Based on the discussion on this point and Hou-San's proposed comment, I have tried to add/edit a few comments in 0001 patch. See, if those make sense to you, it is important to capture the reason and theory we discussed here in the form of comments so that it will be easy to remember the reason in the future. -- With Regards, Amit Kapila.
v17-0001-Distribute-invalidatons-if-change-in-catalog-tab.patch
Description: Binary data
