Problem with database connection

[lars-t-hansen]

I finally set up the sonalyze daemon with the timescale db and it works OK initially but then starts failing with connection busy. Probably somebody must close something.

[lars-t-hansen]

This is the error:

larstha@bling:~/p/Jobanalyzer/code/sonalyze$ ./sonalyze node -remote naic-monitor.uio.no -auth-file ~/.ssh/sonalyzed-auth.netrc -cluster fox.educloud.no -fmt default,json
Sonalyze failed: Remote: {"$schema":"http://localhost:1559/schemas/ErrorModel.json","title":"Bad Request","status":400,"detail":"node: failed to deallocate cached statement(s): conn busy"}

In this case, the same sonalyze command had succeeded not long before.

[lars-t-hansen]

The bug is that the pgx.Rows object returned from databaseConnection.Query must be closed after use.

[lars-t-hansen]

Well, that's one bug. But there must be more problems. With that fixed: I ran about 20 node commands back to back and everything was fine. Then I ran a jobs command, which completed. Then I ran a node command again, which failed. Then I ran the jobs command again, and it failed too with a slightly different error:

Sonalyze failed: Remote: {"$schema":"http://localhost:1559/schemas/ErrorModel.json","title":"Bad Request","status":400,"detail":"jobs: Failed to read log records: failed to deallocate cached statement(s): conn busy"}

[lars-t-hansen]

I could also run a node command, a jobs command, a node command, another jobs command, and then it failed on the next node command. And no other commands came in from anywhere. I was afraid it was a problem with concurrency but so far there's no evidence of that.

[lars-t-hansen]

But if the rows object must be closed, does closing it have any effect on the underlying connection?

[lars-t-hansen]

The initial patch on #913 is not necessary because all the other uses of the Rows objects are operations that will close them.

[lars-t-hansen]

Arguably there is a concurrency issue here. While the connection is under a lock, if the Rows object holds onto the connection (this is implied by the docs) then the connection leaks outside the critical section via the Rows object. I'm not really using it concurrently I think, but who knows what's going on.