public inbox for [email protected]  

help / color / mirror / Atom feed

From: [email protected]
To: Noah Misch <[email protected]>
Cc: Amul Sul <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: tweak to a few index tests to hits ambuildempty() routine.
Date: Sun, 25 Sep 2022 20:49:27 +0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAAJ_b95nneRCLM-=qELEdgCYSk6W_++-C+Q_t+wH3SW-hF50iw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CAAJ_b97etWoGCxOGrtZSZ4sZAh-7NjZvLQbmnqi0ka3Lg2=mQA@mail.gmail.com>
	<[email protected]>
	<[email protected]>

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%3A1...
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, [email protected] 
> 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.

view thread (15+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: tweak to a few index tests to hits ambuildempty() routine.
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox