Hi Alena, On Wed, Sep 16, 2026 at 1:58 PM Alena Rybakina <[email protected]> wrote: > > Both > issues are fixed in the attached v43. The rebase and the fixes needed > more work than I expected, so it took a bit longer. >
CI is complaining about more than one definition of <table id="extvacuumstatistics-pg-stats-vacuum-indexes-columns"> Looks like you mistakenly added this table the second time in the 0007 patch instead of adding new columns to the already existing table added in the 0005. > > 3. Rebase > > Some recent commits in master changed the same code, so v43 also has > these changes: > > * index statistics now have their own stats kind (72a6dad1c911, > f2ccb8e6c591), so the per-index vacuum times moved there (0002); > > * visibilitymap_clear() no longer takes a Relation, so 0009 adds > visibilitymap_clear_rel() for the callers that have one; > > * PgStat_TableCounts was split into two parts (3f2f5e7c4cc); the > visibility map counters are in the non-transactional part; > > * the test from 0004 is now t/018_vacuum_interrupts.pl, because master > added its own t/015_*. > > The structure is the same as before: 0001-0004 are the small core-only > part and are useful on their own; 0005-0008 are the hook and the > extension; 0009 is independent. > I reviewed the 0009 patch. If you add a new external function in visibilitymap.c, i.e., visibilitymap_clear_rel, you should also add it in the INTERFACE ROUTINES list in the beginning of the file. I'd also suggest that the variation of the visibilitymap_clear function taking a Relation should be the main one (and be called visibilitymap_clear), and the variant taking a RelFileLocator should be the additional one for those who don't have a Relation (and be called visibilitymap_clear_no_stats or something). I am not insisting, though. Otherwise, the 0009 looks good to me. Except that I didn't look at the documentation part closely. I'd leave it to the native English speakers. Best regards, Karina Litskevich Postgres Professional: http://postgrespro.com/
