Re: [PATCH v1 0/7] Wait event timing and tracing instrumentation

Hi hackers,

v16 is attached as one archive, v16-wait-event-timing.tar.gz, with 9
patches, based on cea96cdfecb. I send an archive because v15, with nine
separate files, was held for moderation because of its size. 0001, 0002
and 0003 are unchanged. The changes are in 0004 and 0005.

cfbot failed on v15 in two tests.

Windows (MinGW), 006_server_processes, check 8: the standby never showed
a row for the startup process. I found a real bug in 0004 under
EXEC_BACKEND that explains it; the logs fit it, but they do not prove
that this run took exactly this path. The first time a process waits,
0004 decides whether it gets a fixed slot and caches the answer. That
decision needs the extension's shared memory, which an EXEC_BACKEND
child attaches later than a forked one. A contended LWLock wait during
the attach reached the begin hook early, the answer was cached as "no",
and the process never recorded. The fix: the decision is made only after
the attach has finished. I could not run this locally, because
EXEC_BACKEND needs a SysV segment larger than the macOS limit on my
machine. The Windows CI jobs cover it. If 006 fails again, it now prints
the standby processes and which of them have rows.

Linux 32-bit, 016_by_statement_oracle, check 74: a race in the test. The
failing Bind could already be buffered when the test sent it, so no Idle
marker was written between the statements, and the lock wait was counted
with the previous statement (the SET) instead of <no-statement>. Now the
test waits for the Idle marker first. 014 had the same race and has the
same fix. A new pipelined case in 016 checks both orderings.

Documentation: I corrected two marker sequences. The commit WAL flush
and SyncRep happen before TxnCommit, and two statements in one
simple-query message give one TxnCommit at the end. I also documented
three attribution limits: a buffered or pipelined failed request, a
delayed Sync after ExecEnd, and ROLLBACK inside a procedure.

The next version will fix the last two limits.

The overhead measurement of v15 against v14, which I promised in the v15
mail, is still to come.

CI on my fork, tip a8335ae01c8:
https://github.com/DmitryNFomin/postgres/actions/runs/43297158345

Dmitry