pqsql/chanserv: Does not survive PostgreSQL server restart

[pandame]

pqsql currently does not survive the PostgreSQL server restarting or going away at all.

If the PostgreSQL server goes away, it will send some input, signaling PQisBusy == false, but we may not even have queryhead != NULL at the time, leading to a crash. To avoid the crash, queryhead == NULL would first need to be checked, then PQresultStatus(PQgetResult(dbconn)) should be verified to be PGRES_FATAL_ERROR, else the connection may continue to function as intended.

The discussion about PostgreSQL bug 5837 has yielded that the API is meant to be used with PQisBusy to immediately go ahead to PQgetResult, which will then inform about the fatal error. PQstatus will still return CONNECTION_OK despite it obviously not being okay.

However, even if that were to be detected correctly, then there is no reasonable recovery plan:

1. Reconnecting is very risky. Should the connectdb() function hang due to its nature of connecting in a blocking manner, all network I/O will stall, possibly sendq'ing newserv off the network.
2. At the very least, the chanserv does not survive a reload the pqsql module, it crashes at least somewhere around dbhandler/loadmaillocksdone/csc_dochanstat/chanservstdmessage due to invalid parameters. Due to this, waiting for the PostgreSQL server to be confirmed working and then reloading pqsql manually is no option. More modules may or may not fail in similar ways.

PostgreSQL servers may go away even over local connections when admins enable automatic security updates on Linux distributions and the like, due to it being restarted in the process.

[retropc]

it should be able to survive reloading the pqsql module
I don't think the database restarting causing it to crash is much of a problem though