Re: Log connection establishment timings
От | Andres Freund |
---|---|
Тема | Re: Log connection establishment timings |
Дата | |
Msg-id | 7d3fcftmqsm2vounbkmkqnwbqkovsizgdkow46qo7nunau4q2n@pyavjiltbqnu обсуждение исходный текст |
Ответ на | Re: Log connection establishment timings (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: Log connection establishment timings
|
Список | pgsql-hackers |
Hi, On 2025-02-27 11:08:04 -0500, Melanie Plageman wrote: > I was just talking to Andres off-list and he mentioned that the volume > of log_connections messages added in recent releases can really be a > problem for users. For some added color: I've seen plenty systems where almost all the log volume is log_connection messages, which they *have* to enable for various regulatory reasons. It'd still be a lot if we just emitted one message for each connection, but logging three (and possibly four with $thread), for each connection makes it substantially worse. > He said ideally we would emit one message which consolidated these (and make > sure we did so for failed connections too detailing the successfully > completed stages). A combined message would also not *quite* replace all use-cases, e.g. if you want to debug arriving connections or auth problems you do want the additional messages. But yea, for normal operation, I do think most folks want just one message. > However, since that is a bigger project (with more refactoring, etc), > he suggested that we change log_connections to a GUC_LIST > (ConfigureNamesString) with options like "none", "received, > "authenticated", "authorized", "all". Yep. > Then we could add one like "established" for the final message and > timings my patch set adds. I think the overhead of an additional log > message being emitted probably outweighs the overhead of taking those > additional timings. To bikeshed a bit: "established" could be the TCP connection establishment just as well. I'd go for "completed" or "timings". > String GUCs are a lot more work than enum GUCs, so I was thinking if > there is a way to do it as an enum. > > I think we want the user to be able to specify a list of all the log > messages they want included, not just have each one include the > previous ones. So, then it probably has to be a list right? There is > no good design that would fit as an enum. I don't see a way to comfortably shove this into an enum either. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: