Re: Bug in backend/lib/stringinfo.c:enlargeStringInfo()

Nick Wellnhofer <wellnhofer(at)aevum(dot)de> writes:
> Tom Lane wrote:
>> Yeah, it kinda sounds like someone is trying to send an HTTP request to
>> the Postgres port :-(

> I thought about that, but I have TCP disabled. And it's definitely
> triggered by my own Perl code serving dynamic web pages. But it happens
> at completely random places. Maybe it's a bug in DBD::Pg. Is there an
> easy way to log the whole frontend/backend communication?

Not at the low level you'd need to debug this. I'd suggest whipping out
ethereal, tcpdump, or your favorite other TCP packet sniffer, and
running the misbehaving client over local-TCP-loopback until you have
diagnosed the problem.

My original thought about 'HTTP' coming from an independent, misdirected
connection request is clearly wrong, since you'd have to get past the
initial connection handshake to get to ReadCommand. Instead, the HTTP
must be part of the data stream being sent by a legitimate client.

My best guess is that the client is getting out of sync by sending a
packet length word that doesn't match the number of data bytes it
actually transmits. If the length word is, say, 5 bytes too large,
this would result in the backend eating the next packet's length word
and first data byte and then trying to make sense of the second through
fifth data bytes as a new length word. Which fits in with your
observation. So what you need to do is identify which path of control
in the client allows that to happen.

It does sound like the proximate bug is in DBD::Pg, unless that module
allows higher level code to spit whatever-it-pleases onto the connection
--- I'd expect DBD::Pg to be the level responsible for computing packet
length words. I'm not at all familiar with that code, though.

A different line of thought is that some unrelated Perl code within the
client is somehow getting hold of the handle for the DB-connection
socket and pushing out data that was meant to go someplace else
entirely. I have no idea how likely that would be.

regards, tom lane