Re: Add wait events for server logging destination writes

On Sun, Nov 08, 2026 at 01:27:49PM +0900, 신성준 wrote:
> v9 still applies cleanly to current master, so no new version.

+ outer_wait_event_info =
+ pgstat_report_wait_start_nested(WAIT_EVENT_SYSLOG_WRITE);

The concept of nesting is a lie. The wait events you are setting are
not saved in a stack; they're just replaced and saved in place. I am
wondering if something like a pgstat_report_wait_swap() would be more
adapted? If you have a better idea of name, feel free.

Then you would get:
old_event = pgstat_report_wait_swap(new_event);
//do stuff
pgstat_report_wait_swap(old_event);

That would avoid any cloberring of the wait events that an upper layer
calling the elog functions could have set. One API, two calls each
time.

+ * A log message can be written while another wait event is already
+ * published, for instance by an extension that logs from inside its own
+ * wait region, or by quickdie() running in a signal handler. Wait events
+ * are single-slot and pgstat_report_wait_end() clears the field, which
+ * would leave the enclosing region without its event for as long as it
+ * lasts. The nested variants used here and at the other logging writes
+ * put the outer event back once the write is done.

This is AI slop to me. None of this level of details is required.
Even if required, I'd limit that to a few words at most just to say
that we don't want to clobber any information set, if set. But the
intention would be clearly documented if one uses this "swap" API
anyway (or whatever the way you would like to call it) because the old
value is pushed back to my_wait_event_info.

And note that I highly doubt that these commit messages need contents
worth more than 3 screens. So could I suggest that you keep your
agent at bay in terms of quality, please? This does not really help.

Also, perhaps split your new API into a first patch, then write a
second patch that makes use of it. Doing both at the same time feels
confusing.
--
Michael