I’m working on a Proof of Concept with QuestDB, and we’re occasionally experiencing
connection drops when querying the database via Python using psycopg. The error seems to
originate from within the psycopg library, suggesting that the connection to QuestDB might
be dropping unexpectedly. The QuestDB log is quite verbose, but I’m looking for specific
keywords that could provide clues about these disconnection issues. Below is an anonymized
example of the log entries when a disconnection occurred:
YYYY-MM-DDTHH:MM:SS.SSSSSSZ I internal.component.ReaderPool closed 'table_name~ID'
[at=0:0, reason=IDLE]
YYYY-MM-DDTHH:MM:SS.SSSSSSZ I internal.component.ReaderPool closed 'table_name~ID'
[at=0:0, reason=IDLE]
YYYY-MM-DDTHH:MM:SS.SSSSSSZ I internal.component.ReaderPool closed 'table_name~ID'
[at=0:0, reason=IDLE]
YYYY-MM-DDTHH:MM:SS.SSSSSSZ I pg-server disconnected [ip=IP_ADDRESS, fd=FILE_DESCRIPTOR,
src=idle]
This was preceded by the server opening a partition for a query:
YYYY-MM-DDTHH:MM:SS.SSSSSSZ I internal.component.TableReader open partition
/var/lib/questdb/db/table_name~ID/YYYY-MM-DD.ID
Any suggestions on how to diagnose or resolve this issue?
Searching for “disconnect” in the logs can help identify relevant
entries. If your queries are particularly long-running, consider the possibility that this
is related to the query.timeout.sec configuration property, which is set to 60 seconds
by default. You might need to increase this setting to prevent premature disconnection.
To adjust the query.timeout.sec setting, locate it in the db_root_dir/conf/server.conf
file. Also, think about whether your Python application might be pausing while processing
the queried data, as this could trigger an idle connection timeout, leading to the
disconnection.
It’s also wise to examine the pg.net.connection.timeout setting, defaulting to
300,000 milliseconds (5 minutes). Consider increasing this to 900,000 milliseconds (15
minutes) to accommodate longer-running queries.
Ensure your server recognizes the new values by checking the server
logs or executing the SHOW PARAMETERS; SQL command. This command should list all current
configuration settings, including those set via environment variables.
Adjusting these settings should be carefully balanced with
your specific workload and operational environment to avoid unintended side effects, such
as excessively prolonged query execution or resource strain.