On 2019-Apr-25, Peter Geoghegan wrote: > On Fri, Apr 12, 2019 at 10:24 AM Alvaro Herrera > <alvhe...@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
