Hello Mihail, In patch v20-0006-Add-STIR-access-method-and-flags-related-to-auxi.patch, within the "StirMarkAsSkipInserts" function, a critical section appears to be left unclosed. This resulted in an assertion failure during ANALYZE of a table containing a leftover STIR index.
Best regards, Sergey On Mon, Jun 16, 2025, 11:21 PM Sergey Sargsyan < sergey.sargsyan.2...@gmail.com> wrote: > Thank you for the information. Tomorrow, I will also run a few tests to > measure the time required to collect tids from the index; however, since I > do not work with vanilla postgres, the results may vary. > > If the results indicate that this procedure is time-consuming, I maybe > will develop an additional patch specifically for b-tree indexes, as they > are the default and most commonly used type. > > Best regards, > Sergey > > > On Mon, Jun 16, 2025, 11:01 PM Mihail Nikalayeu <mihailnikala...@gmail.com> > wrote: > >> Hello, Sergey! >> >> > I think it's to avoid duplicate errors when adding tuples from STIP to >> the main index, >> > but couldn't we just suppress that error during validation and skip the >> new tuple insertion if it already exists? >> >> In some cases, it is not possible: >> – Some index types (GiST, GIN, BRIN) do not provide an easy way to >> detect such duplicates. >> – When we are building a unique index, we cannot simply skip >> duplicates, because doing so would also skip the rows that should >> prevent the unique index from being created (unless we add extra logic >> for B-tree indexes to compare TIDs as well). >> >> > The main index may get huge after building, and iterating over it in a >> single thread and then sorting tids can be time consuming. >> My tests indicate that the overhead is minor compared with the time >> spent scanning the heap and building the index itself. >> >> > At least I guess one can skip it when STIP is empty. >> Yes, that’s a good idea; I’ll add it later. >> >> > p.s. I noticed that `stip.c` has a lot of functions that don't follow >> the Postgres coding style of return type on separate line. >> Hmm... I’ll fix that as well. >> >> Best regards, >> Mikhail. >> >
