jimmy/postgrest
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

references: updated automatic recovery

Browse Source 
* use bullets were possible and join paragraphs.
* add bug fixes to the unreleased page
This commit is contained in:
steve-chavez
2023-06-07 19:56:05 -05:00
committed by Steve Chavez
parent 188461af7d
commit fb59b82c35
3 changed files with 28 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/references/connection_pool.rst
+18 -19
View File
@@ -3,22 +3,20 @@
Connection Pool Connection Pool
=============== ===============
Every request to an :doc:`API resource <api>` borrows a connection from the connection pool to start a :doc:`transaction <transactions>`. A connection pool is a cache of reusable database connections. It allows serving many HTTP requests using few database connections. Every request to an :doc:`API resource <api>` borrows a connection from the pool to start a :doc:`transaction <transactions>`.
A connection pool is a cache of reusable database connections. It allows serving many HTTP requests using few database connections.
Minimizing connections it’s paramount to performance. Each PostgreSQL connection creates a process, having too many can exhaust available resources. Minimizing connections it’s paramount to performance. Each PostgreSQL connection creates a process, having too many can exhaust available resources.
.. _pool_growth_limit:
.. _dyn_conn_pool: .. _dyn_conn_pool:
Dynamic Connection Pool Dynamic Connection Pool
----------------------- -----------------------
To converve system resources, PostgREST uses a dynamic connection pool. This enables the number of connections in the pool to increase and decrease depending on request traffic. To conserve system resources, PostgREST uses a dynamic connection pool. This enables the number of connections in the pool to increase and decrease depending on request traffic.
If all the connections are being used, a new connection is added to the pool. The pool can grow until it reaches the :ref:`db-pool` size. Note it’s pointless to set this higher than the ``max_connections`` setting in your database. - If all the connections are being used, a new connection is added. The pool can grow until it reaches the :ref:`db-pool` size. Note it’s pointless to set this higher than the ``max_connections`` setting in your database.
- If a connection is unused for a period of time(determined by :ref:`db-pool-max-idletime`, 30 seconds by default), it will be released.
If a connection is unused for a period of time(determined by :ref:`db-pool-max-idletime`, 30 seconds by default), it will be closed.
Connection lifetime Connection lifetime
------------------- -------------------
@@ -27,8 +25,7 @@ Long-lived PostgreSQL connections can consume considerable memory(see `here <htt
Under a busy system, the :ref:`db-pool-max-idletime` won't be reached and the connection pool can have many long-lived connections. Under a busy system, the :ref:`db-pool-max-idletime` won't be reached and the connection pool can have many long-lived connections.
To avoid this problem and save resources, a connection max lifetime(determined by :ref:`db-pool-max-lifetime`, 30 minutes by default) is enforced. To avoid this problem and save resources, a connection max lifetime(determined by :ref:`db-pool-max-lifetime`, 30 minutes by default) is enforced.
After the max lifetime is reached, connections from the pool will be released and news ones will be created. This doesn't affect running requests, only unused connections will be released.
After the max lifetime is reached, connections from the pool will be released and news ones will be created. This doesn't affect running requests. Only unused connections will be released.
Acquisition Timeout Acquisition Timeout
------------------- -------------------
@@ -46,19 +43,21 @@ If the request reaches the timeout, it will be aborted with the following respon
"hint":null, "hint":null,
"message":"Timed out acquiring connection from connection pool."} "message":"Timed out acquiring connection from connection pool."}
Getting this error message is an indicator of a performance issue. To solve it, you can: .. important::
- Reduce your queries execution time. Getting this error message is an indicator of a performance issue. To solve it, you can:
- Reduce your queries execution time.
- Check the request :ref:`explain_plan` to tune your query, this usually means adding indexes. - Check the request :ref:`explain_plan` to tune your query, this usually means adding indexes.
- Reduce the amount of requests. - Reduce the amount of requests.
- Reduce write requests. Do :ref:`bulk_insert` (or :ref:`upsert`) instead of inserting rows one by one. - Reduce write requests. Do :ref:`bulk_insert` (or :ref:`upsert`) instead of inserting rows one by one.
- Reduce read requests. Use :ref:`resource_embedding`. Combine unrelated data into a single request using custom database views or functions. - Reduce read requests. Use :ref:`resource_embedding`. Combine unrelated data into a single request using custom database views or functions.
- Use :ref:`s_procs` for combining read and write logic into a single request. - Use :ref:`s_procs` for combining read and write logic into a single request.
- Increase the :ref:`pool growth limit <pool_growth_limit>`. - Increase the :ref:`db-pool` size.
- Not a panacea since connections can't grow infinitely. Try the previous recommendations before this. - Not a panacea since connections can't grow infinitely. Try the previous recommendations before this.
@@ -67,13 +66,13 @@ Getting this error message is an indicator of a performance issue. To solve it,
Automatic Recovery Automatic Recovery
------------------ ------------------
If the pool loses the connection to the database, it will retry reconnecting using exponential backoff. With 32 seconds being the maximum backoff time between retries. The server will retry reconnecting to the database if connection loss happens.
The retries happen immediately after a connection loss, if :ref:`db-channel-enabled` is set to true(the default). Otherwise they'll happen once a request arrives. - It will retry forever with exponential backoff. 32 seconds being the maximum backoff time between retries. Each of these attempts are :ref:`logged <pgrst_logging>`.
- It will only stop retrying if the server deems the error to be fatal. This can be a password authentication failure or an internal error.
The server reloads the :ref:`schema_cache` and :ref:`configuration` when recovering. - The retries happen immediately after a connection loss, if :ref:`db-channel-enabled` is set to true(the default). Otherwise they'll happen once a request arrives.
- To ensure a valid state, the server reloads the :ref:`schema_cache` and :ref:`configuration` when recovering.
To notify the client of the next retry, the server sends a ``503 Service Unavailable`` status with the ``Retry-After: x`` header. Where ``x`` is the number of seconds programmed for the next retry. - To notify the client of the next retry, the server sends a ``503 Service Unavailable`` status with the ``Retry-After: x`` header. Where ``x`` is the number of seconds programmed for the next retry.
.. _external_connection_poolers: .. _external_connection_poolers:
docs/releases/unreleased.rst
+3 -3
View File
@@ -14,12 +14,12 @@ Configuration
- New :ref:`in_db_config`. It no longer requires high privileges and can be used on cloud-hosted databases. - New :ref:`in_db_config`. It no longer requires high privileges and can be used on cloud-hosted databases.
Documentation improvements
~~~~~~~~~~~~~~~~~~~~~~~~~~
Bug fixes Bug fixes
--------- ---------
- Fix dropping schema cache reload notifications.
- Stop automatic recovery when the error is "no password supplied".
Thanks Thanks
------ ------
postgrest.dict
+2
View File
@@ -66,6 +66,8 @@ Ibarluzea
Inlining Inlining
inlined inlined
Integrations Integrations
idletime
IDLETIME
ilike ilike
imatch imatch
io io