Re: [HACKERS] Incomplete startup packet errors
Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Christoph Berg <myon@debian.org>, pgsql-hackers@lists.postgresql.org
Date: 2019-03-04T12:40:45Z
Lists: 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
Commits
-
Don't log incomplete startup packet if it's empty
- 342cb650e0ff 12.0 landed