Hi, Thanks Kirk, glad it's useful.
Kyotaro Horiguchi wrote: > Should we also consider instrumenting ReportEventW()/ReportEventA()? > They seem to be another Windows-specific logging output path. > > Also, if the intention is to cover all places where logging output > can block, I wonder whether the syslog() calls should be covered as > well. Good points -- both are blocking output paths and there's no real reason to leave them out, so v3 instruments them rather than excluding them with a comment. The intent is exactly to cover the places where logging output can block, so this makes the series consistent. v3 adds two more WaitEventIO events: IO / SyslogWrite - syslog(3) in write_syslog() IO / EventlogWrite - ReportEventW()/ReportEventA() in write_eventlog() Same approach as before: the wait is reported only around the leaf call, using the existing pgstat_report_wait_start()/end() helpers, so it stays allocation-free and safe on the error-reporting path, and the series still touches just elog.c and wait_event_names.txt. This also matches Michael's point on v2 -- each event covers a routine rather than a single call site, so SyslogWrite wraps the syslog(3) calls in write_syslog() and EventlogWrite wraps both ReportEvent variants in write_eventlog(), the same way SysloggerWrite already covers the two writes in write_pipe_chunks(). As before, 0001 is the portable part and 0002 is the Windows part (WriteConsoleW plus the new EventlogWrite). One caveat: EventlogWrite is Windows-only, so I couldn't get a runtime before/after for it here -- I've only confirmed it builds (cfbot's Windows task should cover that). The other events still show up in the sampling I posted earlier. If someone on Windows can exercise the event-log path I'd appreciate a confirmation. Applies cleanly on current master; full build passes locally on both Autoconf and Meson, with no new warnings. Thanks, Seongjun Shin 2026년 6월 1일 (월) 오후 2:49, Kyotaro Horiguchi <[email protected]>님이 작성: > > Hello. > > At Sun, 31 May 2026 17:50:08 +0900, 신성준 <[email protected]> wrote in > > Attached is a short series that adds two WaitEventIO events and reports > > them around those writes: > > > > IO / SysloggerWrite - write(2) to the syslogger pipe > > IO / StderrWrite - write(2) to stderr, and WriteConsoleW() > > > > 0001 adds the events and covers the write(2) paths. 0002 does the > > Windows WriteConsoleW() path, split out since it's platform-specific. > > Should we also consider instrumenting ReportEventW()/ReportEventA()? > They seem to be another Windows-specific logging output path. > > Also, if the intention is to cover all places where logging output can > block, I wonder whether the syslog() calls should be covered as > well. If they are intentionally excluded, perhaps a short comment > explaining the rationale would be useful. > > Regards. > > -- > Kyotaro Horiguchi > NTT Open Source Software Center
v3-0001-Add-wait-events-for-server-logging-destination-wr.patch
Description: Binary data
v3-0002-Add-wait-events-for-Windows-specific-logging-outp.patch
Description: Binary data
