Re: Question for coverage report - Mailing list pgsql-hackers

From Steven Niu
Subject Re: Question for coverage report
Date
Msg-id MN2PR15MB3021A59BBFDE41A60286BB02A7F6A@MN2PR15MB3021.namprd15.prod.outlook.com
Whole thread Raw
In response to Question for coverage report  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Responses RE: Question for coverage report
List pgsql-hackers
Hi,  Hayato, 

I noticed another weird thing in your attached log.  The line 1506 and 1509 should be executed the same number of times.  But line 1506 was executed one more time than line 1509. Maybe a bug of gcov? 

   183433: 1506:  relentry = get_rel_sync_entry(data, relation);
call    0 returned 100%
        -: 1507:
        -: 1508:  /* First check the table filter */
   183432: 1509:  switch (action)

Thanks,
Steven

From: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
Sent: Friday, October 17, 2025 11:40
To: 'pgsql-hackers@lists.postgresql.org' <pgsql-hackers@lists.postgresql.org>
Subject: Question for coverage report

Dear hackers,

While investigating the code coverage I found the questionable report. Do you have
any theories around here?

Attached file is the code coverage report in pgoutput.c, generated by gcov. In
pgoutput_change(), I found that the branch seems not to be chosen but counted.

```
   183433: 1492:        TupleTableSlot *new_slot = NULL;
        -: 1493:
   183433: 1494:        if (!is_publishable_relation(relation))
call    0 returned 100%
branch  1 taken 100% (fallthrough)
branch  2 taken 0%
     1171: 1495:                return;
        -: 1496:
        -: 1497:        /*
        -: 1498:         * Remember the xid for the change in streaming mode. We need to send xid
        -: 1499:         * with each change in the streaming mode so that subscriber can make
        -: 1500:         * their association and on aborts, it can discard the corresponding
        -: 1501:         * changes.
        -: 1502:         */
   183433: 1503:        if (data->in_streaming)
```

IIUC, the line 1494 and 1503 were executed 183433 times. However, the 1495 was also
executed 1171 times. It was strange because the caller won't reach after the return,
count at 1503 should be 183433 - 1171.
Also, it reported that one of the branches was always chosen at 1494, so not sure
why both paths were counted.

I checked [1] and found the same issue; line 1494 and 1503 have the same count
but 1495 also has. Do you know the actual reason?

Locally used configure options:
./configure --enable-cassert --enable-debug --enable-tap-tests CFLAGS="-ggdb -Og -g0 -fno-omit-frame-pointer" --enable-coverage --enable-injection-points

[1]: https://coverage.postgresql.org/src/backend/replication/pgoutput/pgoutput.c.gcov.html

Best regards,
Hayato Kuroda
FUJITSU LIMITED

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Instability of phycodorus in pg_upgrade tests with JIT
Next
From: Michael Paquier
Date:
Subject: Re: Improved TAP tests by replacing sub-optimal uses of ok() with better Test::More functions