Re: [HACKERS] Incomplete startup packet errors
От | Andrew Dunstan |
---|---|
Тема | Re: [HACKERS] Incomplete startup packet errors |
Дата | |
Msg-id | 7cc6d2c1-bd87-9890-259d-36739c247b6c@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Incomplete startup packet errors (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Incomplete startup packet errors
|
Список | pgsql-hackers |
On 3/3/19 3:52 PM, Tom Lane wrote: > I wrote: >> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: >>> Patch proposed by Christoph Berg is here: >>> https://www.postgresql.org/message-id/20190228151336.GB7550%40msg.df7cb.de >> Meh. That doesn't silence only the zero-bytes case, and I'm also >> rather afraid of the fact that it's changing COMMERROR to something >> else. I wonder whether (if client_min_messages <= DEBUG1) it could >> result in trying to send the error message to the already-lost >> connection. It might be that that can't happen, but I think a fair >> amount of rather subtle (and breakable) analysis may be needed. > Concretely, what about doing the following instead? This doesn't provide > any mechanism for the DBA to adjust the logging behavior; but reducing > log_min_messages to DEBUG1 would not be a very pleasant way to monitor for > zero-data connections either, so I'm not that fussed about just dropping > the message period for that case. I kind of like that we no longer need > the weird special case for SSLdone. > > Looks good to me. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: