From: | Steven Niu <niushiji(at)gmail(dot)com> |
---|---|
To: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Question for coverage report |
Date: | 2025-10-17 05:22:12 |
Message-ID: | MN2PR15MB3021A59BBFDE41A60286BB02A7F6A@MN2PR15MB3021.namprd15.prod.outlook.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)hayato(at)fujitsu(dot)com>
Sent: Friday, October 17, 2025 11:40
To: 'pgsql-hackers(at)lists(dot)postgresql(dot)org' <pgsql-hackers(at)lists(dot)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-10-17 05:41:07 | Re: Improved TAP tests by replacing sub-optimal uses of ok() with better Test::More functions |
Previous Message | Fujii Masao | 2025-10-17 05:21:28 | Re: Instability of phycodorus in pg_upgrade tests with JIT |