Yes, with MAX_CONNECTIONS=1 and -O2 the function ginbulkdelete() is
reached while the vacuum test.
But my point is that after 4fb5c794e5 for most developer setups and
buildfarm members, e.g.:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus&dt=2022-09-25%2001%3A01%3A13
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tayra&dt=2022-09-24%2020%3A40%3A00
the ginbulkdelete() most probably is not tested.
In other words, it seems that we've just lost the effect of 4c51a2d1e4:
Add a test case that exercises vacuum's deletion of empty GIN
posting pages. Since this is a temp table, it should now work
reliably to delete a bunch of rows and immediately VACUUM.
Before the preceding commit, this would not have had the desired
effect, at least not in parallel regression tests.
Noah Misch писал 2022-09-25 00:20:
On Wed, Sep 21, 2022 at 02:10:42PM +0700, 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()).
With "make check MAX_CONNECTIONS=1", does that difference between -O0
and -O2
still appear? Compiler optimization shouldn't consistently change
pruning
decisions. It could change pruning decisions probabilistically, by
changing
which parallel actions overlap. If the difference disappears under
MAX_CONNECTIONS=1, the system is likely fine.
