> On 6 Jun 2026, at 21:52, 신성준 <[email protected]> wrote:
>
Hi Seongjun,
Naming is a hard thing. Anyone who can tell syslog from syslogger
without checking man is probably a computer themselves.
+1: a blocking logging write shows as wait_event IS NULL today, which
most tools read as on-CPU. This is very real for us. In our managed
Postgres the root filesystem that holds the logs sits on slow
network-backed HDD, so when the syslogger pipe backs up the backends
stall on the log write and the whole node looks like a CPU overload.
This patch would have made that directly visible.
Worth a line in the commit message: the call that actually blocks on a
slow log device is write_syslogger_file() in the syslogger, which has no
shared memory and isn't in pg_stat_activity. It surfaces on backends as
the pipe fills and they block on the pipe write (SysloggerWrite), so
the backend side is the right, visible layer.
One thing worth checking: wait events are single-slot by design (no
nesting - discussed back in 2016 [0]), and pgstat_report_wait_end()
just writes 0. So if any ereport() path runs while a wait event is
already set, instrumenting the logging write here clobbers that outer
event. Probably rare, but I'm not sure it never happens.
EventlogWrite necessarily shows up in the event list on all platforms
(the generator has no per-platform gating), but the description already
says "Windows event log", so that seems fine...
Thanks for working on this!
Best regards, Andrey Borodin.
[0]
https://www.postgresql.org/message-id/CANP8%2BjKsS6SDo011AUWrLdBcBMv0KJha69t7eFGqEtqx9FVfag%40mail.gmail.com
