"'alvhe...@alvh.no-ip.org'" <alvhe...@alvh.no-ip.org> writes:
> After staring at it a couple of times, I think that the places in
> pqParseInput3() where there's a comment "... moves inStart itself" and
> then "continue;" should have a call to pqTraceOutputMsg(), since AFAIU
> those are the places where the message in question would not reach the
> "Successfully consumed this message" block that prints each message.
After digging around a little, I remember that there are a *bunch*
of places in fe-protocol3.c that advance inStart. The cleanest way
to shove this stuff in without rethinking that logic would be to
call pqTraceOutputMsg immediately before each such advance (using
the old inStart value as the message start address). A possible
advantage of doing it like that is that we'd be aware by that point
of whether we think the message is good or bad (or whether it was
good but we failed to process it, perhaps because of OOM). Seems
like that could be a useful thing to include in the log.
Or we could rethink the logic. It's not quite clear to me, after
all this time, why getRowDescriptions() et al are allowed to
move inStart themselves rather than letting the main loop in
pqParseInput3 do it. It might well be an artifact of having not
rewritten the v2 logic too much.
regards, tom lane
