stats: reconnect to postgres in case of error

[ghost]

reconnects if no cursor can be fetched
still leads to one 500 connection interestingly, but the next will
succeed

[bernhardreiter]

Hi @wagner-certat, thanks for the pull request!

This seems to be an attempt to solve #12 .
After a brief look I'm unsure about the side effects to robustness,
what if there already is something, re-doing setup may change the behaviour then.
Do you have a situation where it is not possible to get a cursor?
(Which is different from the case outlined in #12).
I'm trying to understand how this could happen in production.

[ghost]

Hi,

We did have this problem and if I remember correctly, it was after a restart of the posgresql server.
If the connection gets lost, the next command to the database (getting the/a cursor) server will not succeed. Without re-initializing the connection, you'd need to restart the web-/uwsgi-server in this case.

[bernhardreiter]

Okay, a database restart is the only known observed situation so far. A nice improvement would be to switch the code forwards using a connection pool. For this pull request to be merged as a simpler improvement, I'd like to understand the side effects of the second setup() better.

[ghost]

Okay, a database restart is the only known observed situation so far.

But can happen and the application should still be usable after such an event.

For this pull request to be merged as a simpler improvement, I'd like to understand the side effects of the second setup() better.

QUERY_EVENT_SUBQUERY is not reset and entries removed from the configuration will stay there. I can imagine, that's acceptable but otherwise 6669211 provides an untested fix (can test it of course if you think the commit is required)