Re: Introduce "log_connection_stages" setting.
От | Melanie Plageman |
---|---|
Тема | Re: Introduce "log_connection_stages" setting. |
Дата | |
Msg-id | CAAKRu_Yj6GSEFvjfmVKC-RS_x5-cA_ZFwe=FCEnhwyyCJwEg1g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Introduce "log_connection_stages" setting. (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: Introduce "log_connection_stages" setting.
|
Список | pgsql-hackers |
On Mon, Mar 3, 2025 at 9:40 AM Melanie Plageman <melanieplageman@gmail.com> wrote: > > I'd certainly like to merge it in 18. The patch itself needs more > work, which I'm planning on doing this week. I think we have a > reasonable amount of consensus on using GUC_LIST_INPUT. > > I am less sure about merging log_disconnections into log_connections. > I think it makes sense in principle. But, in 18, when people satisfied > with existing behavior change log_connections from 'on' to 'all' to > comply with the new format, they will get the disconnections messages. > > I am still somewhat nervous about merging the patch in general and > people being surprised because they didn't pay attention to the > discussion and now log_connections is different and they would have > -1'd if they'd been paying attention. Okay, I got cold feet today working on this. I actually think we probably want some kind of guc set (set like union/intersection/etc not set like assign a value) infrastructure for gucs that can be equal to any combination of predetermined values. See my musings on this here [1]. It is too late in the cycle for me to get something like that done, but I am interested in working on it next release. IIRC you did not deprecate log_connections in your patch, but adding another guc that is a staged version of it seems not as good as turning log_connections into a more modular GUC. But I just don't think we want to move log_connections/disconnections toward a string/list. - Melanie [1] https://www.postgresql.org/message-id/CAAKRu_a5-7sUP%2BQ6YD5emQYS1w7ffBDUNf-NMbcxR-dpOdGehw%40mail.gmail.com
В списке pgsql-hackers по дате отправления: