Dear Andres,
Thanks for giving comments for my test!
> This is not a useful measurement for overhead introduced in
> ReserveXLogInsertLocation(). What you're measuring here is the number of
> commits/second, not the WAL insertion rate. The number of commits/second is
> largely determined by your disk's write latency, the batching of WAL flushes
> and things like the SLRU code.
You meant that committing transactions is huge work so that it may hide
performance
regression of ReserveXLogInsertLocation(), right? But...
> To measure the effect of changes to ReserveXLogInsertLocation() use something
> like this as a pgbench script:
> SELECT pg_logical_emit_message(false, \:client_id::text, '1'),
> generate_series(1,
> 10000) OFFSET 10000;
I don't think the suggested workload is useful here.
pg_logical_emit_message(transactional = false)
does insert the WAL without the commit, i.e., xlcommitrecis always NULL.
This means backends won't go through added codes in ReserveXLogInsertLocation().
## Appendix - gdb results
1. connected a postgres instance
2. attached the backend process via gdb
3. added a breakpoint to XLogInsert
4. executed a command: SELECT pg_logical_emit_message(false, '1', '1'),
generate_series(1, 10000) OFFSET 10000;
5. the process stopped at the break point. Backtrace was:
```
(gdb) bt
#0 XLogInsert (rmid=21 '\025', info=0 '\000') at xloginsert.c:479
#1 0x000000000094a640 in LogLogicalMessage (prefix=0x23adfd0 "1",
message=0x23a34c4 "1~\177\177\060", size=1,
transactional=false, flush=false) at message.c:72
#2 0x000000000094a545 in pg_logical_emit_message_bytea (fcinfo=0x23a65d0) at
logicalfuncs.c:376
#3 0x000000000094a56f in pg_logical_emit_message_text (fcinfo=0x23a65d0) at
logicalfuncs.c:385
```
6. confirmed xlcommitrec was NULL
```
(gdb) p xlcommitrec
$1 = (xl_xact_commit *) 0x0
```
Best regards,
Hayato Kuroda
FUJITSU LIMITED
