On 2022-Sep-21, a.kozhemya...@postgrespro.ru wrote: > After analyzing this, I found out why we don't reach that Assert but we have > coverage shown - firstly, it reached via another test, vacuum; secondly, it > depends on the gcc optimization flag. We reach that Assert only when using > -O0. > If we build with -O2 or -Og that function is not reached (due to different > results of the heap_prune_satisfies_vacuum() check inside > heap_page_prune()). > But as the make checks mostly (including the buildfarm testing) performed > with -O2/-Og, it looks like that after 4fb5c794e5 we have lost the coverage > provided by the 4c51a2d1e4.
Hmm, so if we merely revert the change to gin.sql then we still won't get the coverage back? I was thinking that a simple change would be to revert the change from temp to unlogged for that table, and create another unlogged table; but maybe that's not enough. Do we need a better test for GIN vacuuming that works regardless of the optimization level? -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Investigación es lo que hago cuando no sé lo que estoy haciendo" (Wernher von Braun)
