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

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

  1. Don't log incomplete startup packet if it's empty