From: | a(dot)kozhemyakin(at)postgrespro(dot)ru |
---|---|
To: | Amul Sul <sulamul(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, thomas(dot)munro(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, alvherre(at)alvh(dot)no-ip(dot)org, sulamul(at)gmail(dot)com, noah(at)leadboat(dot)com |
Subject: | Re: tweak to a few index tests to hits ambuildempty() routine. |
Date: | 2022-09-21 07:10:42 |
Message-ID: | 6c9ec3889fb13b7ffcd9e1dc3e1f1e08@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Amul Sul писал 2022-09-14 14:28:
> On Wed, Sep 14, 2022 at 12:16 PM <a(dot)kozhemyakin(at)postgrespro(dot)ru> wrote:
>>
>> I still wonder, if assert doesn't catch why that place is marked as
>> covered here?
>> https://coverage.postgresql.org/src/backend/access/gin/ginvacuum.c.gcov.html
>>
>
> Probably other tests cover that.
>
> Regards,
> Amul
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2022-09-21 07:39:41 | Multi-insert related comment in CopyFrom() |
Previous Message | Michael Paquier | 2022-09-21 06:59:36 | Re: Refactor backup related code (was: Is it correct to say, "invalid data in file \"%s\"", BACKUP_LABEL_FILE in do_pg_backup_stop?) |