On 2022-Sep-21, a.kozhemyakin@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)
