On Fri, 28 Nov 2025 at 18:58, Hannu Krosing <[email protected]> wrote: > > On Fri, Nov 28, 2025 at 5:58 PM Matthias van de Meent > <[email protected]> wrote: > > > ... > > I'm a bit worried, though, that LR may lose updates due to commit > > order differences between WAL and PGPROC. I don't know how that's > > handled in logical decoding, and can't find much literature about it > > in the repo either. > > Now the reference to logical decoding made me think that maybe to real > fix for CIC would be to leverage logical decoding for the 2nd pass of > CIC and not wore about in-page visibilities at all.
-1: Requiring the logical decoding system just to reindex an index without O(tablesize) lock time adds too much overhead, and removes features we currently have (CIC on unlogged tables). wal_level=logical *must not* be required for these tasks if we can at all avoid it. I'm also not sure whether logical decoding gets access to the HOT information of the updated tuples involved, and therefore whether the index build can determine whether it must or can't insert the tuple. I don't think logical decoding is sufficient, because we don't know which tuples were already inserted into the index by their own backends, so we don't know which tuples' index entries we must skip. Kind regards, Matthias van de Meent. PS. I think the same should be true for REPACK CONCURRENTLY, but that's a new command with yet-to-be-determined semantics, unlike CIC which has been part of PG for 6 years.
