Matthias Apitz <guru@xxxxxxxxxxx> 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
