El día martes, mayo 05, 2020 a las 04:18:02p. m. -0400, Tom Lane escribió:
> 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.
$ printf "0x%x\n" 1650422894
0x625f746e
$ printf "0x%x\n" 1650422894 | xxd -r
b_tn
I will try to add in the case of the 'bogus received message length...'
more logging of the content of the message.
The client in question is written in ESQL/C and I will enable the (very
good) ESQL/C logging feature of this interface to get an understanding
what the client was sending before this connection gets stuck. We will
produce tons of log files, but apart of Linux strace or tcpdump with
even more tons, I don't see any way at the moment. The situation is
relatively seldom.
Thanks
matthias
--
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub