[pgsql tracing] Incorrect req & resp matching

[sync-by-unito[bot]]

According to [~accountid:5e26aeb0db3c400c9ddecd9e] 's report:

I have the demo app from src/stirling/source_connectors/socket_tracer/protocols/pgsql/testing/ running on my cluster. At first stirling will trace the pgsql traffic from it, but if I leave it running for a little while (~10m), it no longer shows up in the pgsql traffic. Looking at the postgres logs I can confirm that queries are still being made from the demo pod to postgres. If I delete the demo pod and the postgres pod and let them restart then the pgsql data gets picked up again for a little while and then eventually stops working again.

while you're looking into that, there's also occasionally some SELECT commands that get paired with the wrong response, eg in this case a SELECT command gets paired with the response to an INSERT command:

req: EXECUTE [SELECT * FROM person WHERE first_name=Jason], 
resp: INSERT 0 1,

Similarly sometimes a INSERT INTO command has a SELECT command's resp:

req: EXECUTE [query=[INSERT INTO person (first_name, last_name, email) VALUES ($1, $2, $3)], params=[Jason, Moiron, [email protected]]], 
resp: Jason,Moiron,[email protected]
Jason,Moiron,[email protected]
Jason,Moiron,[email protected]

and I've also seen a case where the incorrect params are stitched into the EXECUTE command, eg. I saw the params from one of the INSERT INTO statements stitched with one of the SELECT statements

┆Issue is synchronized with this Jira Bug by Unito