Re: Invalid length of startup packet

>
> timestamp [PID] LOG: received connection from foo.bar port 12345
> timestamp [PID] FATAL: Invalid length of startup packet
>
> The PID in the first of these messages would already be the PID of the
> forked-off child, so there would be a clear correlation to
> the following
> failure message, even if other connection requests were being
> processed
> at about the same time.

That works for me, although won't there will be some redundancy in some
cases?
May 28 09:14:55 vault pgqv[4332]: [1] DEBUG:  connection:
host=172.21.41.62:3586 user=dbuser database=test

I can live with that redundancy, especially considering that some of our
logging tools rely on those three pieces of information being together.

If the output becomes something similar to this:
May 28 09:14:55 vault pgqv[4332]: [1] DEBUG:  connection:
host=172.21.41.62:3586
May 28 09:14:55 vault pgqv[4332]: [2] DEBUG:  authorize: user=dbuser
database=test

Or
May 28 09:14:55 vault pgqv[4332]: [1] DEBUG:  connection:
host=172.21.41.62:3586
May 28 09:14:55 vault pgqv[4332]: [2] FATAL: Invalid length of startup
packet
Then we (my group) could adjust.  We're flexible. :)

To answer an earlier question:
> the text of the error message.  So the "attempted connection" message
> would have to be logged unconditionally for every connection attempt.
> Does that seem useful?  Would you want it to be automatic when
> LOG_CONNECTIONS is on, or should it require some higher-than-normal
> debug setting?

I think that it should be automatic when LOG_CONNECTIONS is on. I have
connection logging on specifically so I can discover this _type_ of problem.
(specifically, relating problems seen later in a connection back to the
client that initiated it)

-ron