Re: Unfiltered server logs routing via a new elog hook or existing emit_log_hook bypassing log_min_message check
От | Bharath Rupireddy |
---|---|
Тема | Re: Unfiltered server logs routing via a new elog hook or existing emit_log_hook bypassing log_min_message check |
Дата | |
Msg-id | CALj2ACXauMeoMH=rDCZ+jJXHGDmSwjVkAvkQ9Aac8x4b-NDwCQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Unfiltered server logs routing via a new elog hook or existing emit_log_hook bypassing log_min_message check (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, May 2, 2022 at 7:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Julien Rouhaud <rjuju123@gmail.com> writes: > > On Mon, May 02, 2022 at 07:24:04PM +0530, Bharath Rupireddy wrote: > >> I basically want to avoid normal users/developers setting any > >> parameter (especially the superuser-only log_min_message GUC, all > >> users might not have superuser access in production environments) or > >> making any changes to the running server except just LOADing the > >> server log routing/intercepting extension. > > > The kind of scenario you mentioned didn't seem "normal users" oriented. Note > > that LOAD is restricted to superuser anyway. > > It seems completely silly to be worrying that setting a GUC in a > particular way is too hard for somebody who's going to be installing > a loadable extension. In any case, if you wanted to force the issue > you could set log_min_messages in the extension's _PG_init function. Thanks Tom and Julien. I developed a simple external module called pg_intercept_logs [1]. [1] https://github.com/BRupireddy/pg_intercept_server_logs Regards, Bharath Rupireddy.
В списке pgsql-hackers по дате отправления: