On Mon, May 2, 2022 at 6:32 PM Julien Rouhaud <rjuju...@gmail.com> wrote: > > Hi, > > On Mon, May 02, 2022 at 05:11:34PM +0530, Bharath Rupireddy wrote: > > > > Currently the emit_log_hook gets called only for the log messages of > > type <= log_min_message i.e when edata->output_to_server is true [1], > > which means that I can't use an implementation of emit_log_hook to > > just intercept, say, all DEBUGX messages without interrupting the > > actual server logs flow and changing the log_min_message. > > [...] > > If I had > > postgres elog hook, say emit_unfiltered_log_hook [2], I can basically > > write an external module (with a bunch of GUCs say log_level to route, > > place to store the logs, even an option to filter logs based on text > > say logs containing word 'replication', max disk space that these > > routed logs would occupy etc.) implementing emit_unfiltered_log_hook > > to just route the interested logs to a cheaper storage (for debugging > > purposes), after analysis I can disable the external module and blow > > away the routed logs. > > Unless I'm missing something you can already do all of that with the current > hook, since as mentioned in the comment above the hook can disable the > server's > logging: > > * Call hook before sending message to log. The hook function is > allowed > * to turn off edata->output_to_server, so we must recheck that > afterward. > > So you can configure your server with a very verbose log_min_message, and have > the same setting in your own extension to disable output_to_server after its > own processing is done.
No. The emit_log_hook isn't called for all the log messages, but only when output_to_server = true which means, say my log_min_messages is 'WARNING', the hook isn't called for the messages say elevel above it (NOTICE, INFO, DEBUGX). Regards, Bharath Rupireddy.
