Re: tweak to a few index tests to hits ambuildempty() routine.

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(dot)kozhemyakin(at)postgrespro(dot)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.