On 2019-Apr-25, Peter Geoghegan wrote:
> On Fri, Apr 12, 2019 at 10:24 AM Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > Hmm, it's odd, because
> > https://coverage.postgresql.org/src/backend/access/nbtree/nbtutils.c.gcov.html
> > still shows that function doing that. pg_config shows:
> >
> > $ ./pg_config --configure
> > '--enable-depend' '--enable-coverage' '--enable-tap-tests' '--enable-nls' '--with-python' '--with-perl'
'--with-tcl''--with-openssl' '--with-libxml' '--with-ldap' '--with-pam' 'CFLAGS=-O0'
>
> So, we're currently using this on coverage.postgresql.org? We've switched?
Yes, I changed it the day you first suggested it.
> I noticed a better example of weird line counts today, this time
> within _bt_check_rowcompare():
>
> 1550 4 : cmpresult = 0;
> 1551 4 : if (subkey->sk_flags & SK_ROW_END)
> 1552 1292 : break;
> 1553 0 : subkey++;
> 1554 0 : continue;
>
> I would expect the "break" statement to have a line count that is no
> greater than that of the first two lines that immediately precede, and
> yet it's far far greater (1292 is greater than 4). It looks like there
> has been some kind of loop transformation.
Maybe it takes more than -O0 in cflags to disable those, but as I said,
the compile lines do show the -O0.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services