Matthias Apitz <guru@unixarea.de> writes:
> El día lunes, abril 27, 2020 a las 09:40:39a. m. -0400, Tom Lane escribió:
>> If you're in a position to run a modified server, you could try
>> inserting a debug log message:
> I've added the printout of the length in this case and another one, and
> see this in the server's log file:
> 2020-05-04 10:05:49.977 CEST [32092] LOG: invalid length 33554940 of startup packet
> 2020-05-04 10:05:50.207 CEST [32094] LOG: invalid length 33554940 of startup packet
> 2020-05-04 12:32:50.781 CEST [20334] LOG: bogus received message length: 1650422894
> 2020-05-04 12:36:41.293 CEST [20380] LOG: bogus received message length: 1650422894
> 2020-05-04 12:39:39.461 CEST [20441] LOG: bogus received message length: 1650422894
> 2020-05-04 13:01:50.566 CEST [24222] LOG: bogus received message length: 1650422894
Hmph. That confirms that we're getting a bogus message length, but not
much more. It's quite interesting though that the bogus value is always
the same. According to my calculator 1650422894 corresponds to ASCII
"b_tn", or possibly "nt_b" depending on what you want to assume about
endianness, which looks tantalizingly like it could be a fragment of a
SQL query. So I'm still leaning to the idea that the client has sent
a malformed query stream --- but how? Or if the data got corrupted in
transit, how did that happen?
Can you work backwards to what the client was doing just before the
point at which it hangs? It's likely that the particular PQprepare
call it's stuck on is just the victim of prior misfeasance. If you
can find "b_tn" or "nt_b" in any strings the client should have been
sending up to this point, that might shed light too.
regards, tom lane