Re: [HACKERS] Incomplete startup packet errors
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Christoph Berg <myon@debian.org>, pgsql-hackers@lists.postgresql.org
Date: 2019-03-03T20:52:31Z
Lists: pgsql-hackers
Attachments
- alternate-fix-for-incomplete-packet-logging.patch (text/x-diff) patch
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. regards, tom lane
Commits
-
Don't log incomplete startup packet if it's empty
- 342cb650e0ff 12.0 landed