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
pgoutput.c.gcov.out
Description: pgoutput.c.gcov.out
