diff --git a/docs/conf.py b/docs/conf.py index c754b47b5..5125f8299 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -57,9 +57,9 @@ copyright = u'2017, ' + author # built documents. # # The short X.Y version. -version = u'11.0' +version = u'11.1' # The full version, including alpha/beta/rc tags. -release = u'11.0.1' +release = u'11.1.0' # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. diff --git a/docs/references/api/stored_procedures.rst b/docs/references/api/stored_procedures.rst index 45c5e62f0..e5098864b 100644 --- a/docs/references/api/stored_procedures.rst +++ b/docs/references/api/stored_procedures.rst @@ -65,7 +65,7 @@ The client can call it by posting an object like Calling with GET ---------------- -If the function doesn't modify the database, it will also run under the GET method(see :ref:`access_mode`). +If the function doesn't modify the database, it will also run under the GET method (see :ref:`access_mode`). .. tabs:: diff --git a/docs/references/configuration.rst b/docs/references/configuration.rst index 9b44ac3ab..50e71c17d 100644 --- a/docs/references/configuration.rst +++ b/docs/references/configuration.rst @@ -158,8 +158,8 @@ db-extra-search-path String public Y PGRST_DB_EXTRA_ db-max-rows Int ∞ Y PGRST_DB_MAX_ROWS pgrst.db_max_rows db-plan-enabled Boolean False Y PGRST_DB_PLAN_ENABLED pgrst.db_plan_enabled db-pool Int 10 PGRST_DB_POOL -db-pool-max-idletime Int 30 PGRST_DB_POOL_MAX_IDLETIME db-pool-acquisition-timeout Int 10 PGRST_DB_POOL_ACQUISITION_TIMEOUT +db-pool-max-idletime Int 30 PGRST_DB_POOL_MAX_IDLETIME db-pool-max-lifetime Int 1800 PGRST_DB_POOL_MAX_LIFETIME db-pre-request String Y PGRST_DB_PRE_REQUEST pgrst.db_pre_request db-prepared-statements Boolean True Y PGRST_DB_PREPARED_STATEMENTS pgrst.db_prepared_statements @@ -295,6 +295,13 @@ db-pool Number of maximum connections to keep open in PostgREST's database pool. +.. _db-pool-acquisition-timeout: + +db-pool-acquisition-timeout +--------------------------- + + Specifies the maximum time in seconds that the request will wait for the pool to free up a connection slot to the database. + .. _db-pool-max-idletime: db-pool-max-idletime @@ -304,13 +311,6 @@ db-pool-max-idletime Time in seconds to close idle pool connections. -.. _db-pool-acquisition-timeout: - -db-pool-acquisition-timeout ---------------------------- - - Specifies the maximum time in seconds that the request will wait for the pool to free up a connection slot to the database. - .. _db-pool-max-lifetime: db-pool-max-lifetime diff --git a/docs/references/connection_pool.rst b/docs/references/connection_pool.rst index a196ee689..c1ff099bd 100644 --- a/docs/references/connection_pool.rst +++ b/docs/references/connection_pool.rst @@ -13,24 +13,24 @@ Minimizing connections it’s paramount to performance. Each PostgreSQL connecti Dynamic Connection Pool ----------------------- -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. +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. 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 all the connections are being used, a new connection is added. The pool can grow until it reaches the :ref:`db-pool` size. Note that 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. Connection lifetime ------------------- -Long-lived PostgreSQL connections can consume considerable memory(see `here `_ for more details). +Long-lived PostgreSQL connections can consume considerable memory (see `here `_ for more details). 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. -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. +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 new ones will be created. This doesn't affect running requests, only unused connections will be released. Acquisition Timeout ------------------- -If all the available connections in the pool are busy, an HTTP request will wait until reaching a timeout(determined by :ref:`db-pool-acquisition-timeout`, 10 seconds by default). +If all the available connections in the pool are busy, an HTTP request will wait until reaching a timeout (determined by :ref:`db-pool-acquisition-timeout`, 10 seconds by default). If the request reaches the timeout, it will be aborted with the following response: @@ -68,9 +68,9 @@ Automatic Recovery The server will retry reconnecting to the database if connection loss happens. -- It will retry forever with exponential backoff. 32 seconds being the maximum backoff time between retries. Each of these attempts are :ref:`logged `. +- It will retry forever with exponential backoff, with a maximum backoff time of 32 seconds between retries. Each of these attempts are :ref:`logged `. - 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 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. +- 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. diff --git a/docs/releases/unreleased.rst b/docs/releases/v11.1.0.rst similarity index 98% rename from docs/releases/unreleased.rst rename to docs/releases/v11.1.0.rst index 1044e92d8..55cba22e2 100644 --- a/docs/releases/unreleased.rst +++ b/docs/releases/v11.1.0.rst @@ -1,5 +1,5 @@ -Unreleased -========== +11.1.0 +====== Features --------