>
> 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