Horton
Menu

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

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: a.kozhemyakin@postgrespro.ru
Cc: Amul Sul <sulamul@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, thomas.munro@gmail.com, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org
Date: 2022-09-24T17:20:20Z
Lists: pgsql-hackers 
On Wed, Sep 21, 2022 at 02:10:42PM +0700, 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()).

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.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid loss of code coverage with unlogged-index test cases.

  2. Use --no-unlogged-table-data in t/027_stream_regress.pl.

  3. Cover brin/gin/gist/spgist ambuildempty routines in regression tests

  4. Improve test coverage of ginvacuum.c.