Before this commit, the following execution of a prepared statement
returned nothing even though the database had 2 rows to be returned:
nwaku-db-1 | 2023-12-14 12:55:17.575 UTC [73] LOG: execute SelectWithoutCursorAsc: SELECT storedAt, contentTopic, payload, pubsubTopic, version, timestamp, id FROM messages
nwaku-db-1 | WHERE contentTopic IN ($1) AND
nwaku-db-1 | pubsubTopic = $2 AND
nwaku-db-1 | storedAt >= $3 AND
nwaku-db-1 | storedAt <= $4
nwaku-db-1 | ORDER BY storedAt ASC LIMIT $5;
nwaku-db-1 | 2023-12-14 12:55:17.575 UTC [73] DETAIL: parameters: $1 =
'my/ctopic/1,my/ctopic/2', $2 = '/waku/2/default-waku/proto', $3 = '1702552968570786800', $4 = '1702552968585347557', $5 = '101'
The reason why it is not returning anything is that the 'IN' statement doesn't work when using prepared statements with multiple items. It only works when the 'IN' content, i.e. $1, contains one single item.
* db_postgres: use prepared statements on most freq select queries
* db_postgres/dbconn.nim adding better feedback in case of query error
* dbconn: use of isOkOr
* pgasyncpool: refactor to reduce code (valueOr, catch:)
* db_postgres, postgres_driver: better performance by using callback.
There were a bunch of milliseconds being lost due to multiple-row
processing. This commit aims to have the minimum possible row
process time.
* pgasyncpool: clarifying logic around pool conn management.
* db_postgres: removing duplicate code and more searchable proc names.
* postgres_healthcheck: validate once per minute instead of 30 sec
* postgres_driver.nim: change MaxNumCons from 5 to 50
* postgres_driver.nim: split connPool into writeConPool and readConPool
This aims to avoid clashes in insert and select queries
because the inserts and selects can happen concurrently
in relay and store events, respectively.
It starts an asynchronous infinite task that checks the connectivity
with the database. In case of error, the postgres_healthcheck task
tries to reconnect for a while, and if it determines that the connection
cannot be resumed, then it invokes a callback indicating that
situation. For the case of the `wakunode2` app, this callback
quits the application itself and adds a log trace indicating
the connectivity issue with the database.
