On Wed, 10 Jul 2024 at 16:58, Greg Sabino Mullane <htamf...@gmail.com> wrote: --snip--
> Why not build a more generic log filtering case? > > I looked into this, but it would be a large undertaking, given the way our > logging system works. And as per above, I don't think the pain would be > worth it, as duration covers 99% of the use cases for separate logs. > The other category of logging which would benefit from a separate file is audit. It also can create massive volumes of log content. Splitting audit information off into a separate file for use by a separate team or function is also a request I have heard from some financial institutions adopting Postgres. With audit being provided by an extension, this would become quite an intrusive change. Why not use an extension for this? > > I did start this as an extension, but it only goes so far. We can use > emit_log_hook, but it requires careful coordination of open filehandles, > has to do inefficient regex of every log message, and cannot do things like > log rotation. > Would an extension be able to safely modify the message_type field you have added using emit_log_hook? If so, the field becomes more of a log destination label than a type marker. If an extension could hook into the log file creation/rotation process, that would be a nice basis for enabling extensions (I'm particularly thinking of pgAudit) to manage separate logging destinations.
