{"kind": "conn", "major": "18", "item": {"slug": "load-balance-hosts", "name": "load_balance_hosts", "name_zh": "", "category": "Connection destination", "summary": "Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:", "aliases": ["PGLOADBALANCEHOSTS", "load_balance_hosts"], "content_hash": "b0277b765f98ea0e48d0d5b60fec2615ce826ebc0ecc72275ec4232dc190d94f", "versions": {"16": {"facts": [{"label": "Client library", "value": "libpq 16.15"}, {"label": "Manual definition", "value": "Documented"}, {"label": "Source environment fallback", "value": "PGLOADBALANCEHOSTS"}, {"label": "Compiled fallback expression", "value": "DefaultLoadBalanceHosts"}], "tables": [{"key": "environment", "rows": [{"name": {"url": "/docs/16/libpq-envars.html", "text": "PGLOADBALANCEHOSTS"}, "description": "PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."}], "title": "Environment fallback", "columns": [{"key": "name", "label": "Variable"}, {"key": "description", "label": "Documented behavior"}]}], "keyword": "load_balance_hosts", "related": [{"url": "/docs/16/libpq-pgservice.html", "label": "Connection service file"}, {"url": "/docs/16/libpq-pgpass.html", "label": "Password file"}, {"url": "/docs/16/libpq-envars.html", "label": "All libpq environment variables"}], "release": {"ref": "https://ftp.postgresql.org/pub/source/v16.15/postgresql-16.15.tar.bz2", "label": "16.15", "major": "16", "channel": "stable", "manifest": {"pdf": {"A4": {"url": "/files/documentation/pdf/16/postgresql-16-A4.pdf", "bytes": 15282337, "pages": 3055, "sha256": "4bb6c1f63deedac98736d8c4c7bc0fad0ac24e85b07e21ee10411872f06afd06", "built_at": "2026-09-26"}, "US": {"url": "/files/documentation/pdf/16/postgresql-16-US.pdf", "bytes": 15164148, "pages": 3220, "sha256": "5b6b6166c89991199e144bb0ae34c17a5f29826251dbf19db1abc0df3a3e771b", "built_at": "2026-09-26"}}, "tree": "16", "index": "index.html", "major": "16", "pages": 1169, "release": "16.15", "source_url": "https://ftp.postgresql.org/pub/source/v16.15/postgresql-16.15.tar.bz2", "svg_assets": 3, "source_mode": "en HTML verified against the pinned official archive", "source_sha256": "c1575341fa7bd40f5274ea465b34390f4dc64cdd0770af327005caaeb9f6b7ed"}, "revision": "3c21e58b35318021716440e67bb8bafd392b6a2b965a244d90e9e33c99e0bdef", "evidence_kind": "English manual and source declarations", "source_sha256": "c1575341fa7bd40f5274ea465b34390f4dc64cdd0770af327005caaeb9f6b7ed"}, "sources": [{"url": "/docs/16/libpq-connect.html#LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "file": "libpq-connect.html", "label": "16.15 English manual \u00b7 libpq-connect.html", "anchor": "LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "sha256": "a88a6c8f0e2229b1e469ca3fcf95d6cba163af369f2c232c04c07ba0a5b64242"}, {"url": "https://ftp.postgresql.org/pub/source/v16.15/postgresql-16.15.tar.bz2", "file": "src/interfaces/libpq/fe-connect.c", "label": "16.15 libpq connection option declarations", "sha256": "ccc43473f7a01820f1ef625a8704548db03499bdee02ef943adbd1329f17f9e7", "archive_sha256": "c1575341fa7bd40f5274ea465b34390f4dc64cdd0770af327005caaeb9f6b7ed"}, {"url": "/docs/16/libpq-envars.html", "file": "libpq-envars.html", "label": "16.15 English manual \u00b7 libpq-envars.html", "anchor": "", "sha256": "2dd3190c2f6b9e0d3051b7cc325bb30dad84b29e53035680aa622409ad00fe28"}, {"url": "/docs/16/libpq-pgservice.html", "file": "libpq-pgservice.html", "label": "16.15 English manual \u00b7 libpq-pgservice.html", "anchor": "", "sha256": "d636639599c1db7c0eb9da6c188abfbf7c590bb2ae9367e7fff05863bb9bd0db"}], "sections": [{"title": "Default resolution and service-file precedence", "paragraphs": ["The following environment variables can be used to select default connection parameter values, which will be used by PQconnectdb , PQsetdbLogin and PQsetdb if no value is directly specified by the calling code. These are useful to avoid hard-coding database connection information into simple client applications, for example.", "Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf . On Microsoft Windows, it is named %APPDATA%\\postgresql\\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified by setting the environment variable PGSERVICEFILE . The system-wide file is named pg_service.conf . By default it is sought in the etc directory of the PostgreSQL installation (use pg_config --sysconfdir to identify this directory precisely). Another directory, but not a different file name, can be specified by setting the environment variable PGSYSCONFDIR .", "Connection parameters obtained from a service file are combined with parameters obtained from other sources. A service file setting overrides the corresponding environment variable, and in turn can be overridden by a value given directly in the connection string. For example, using the above service file, a connection string service=mydb port=5434 will use host somehost , port 5434 , user admin , and other parameters as set by environment variables or built-in defaults."]}, {"title": "Environment variable evidence", "paragraphs": ["PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."]}], "signature": "load_balance_hosts", "documented": true, "description": ["Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:"], "environment": [{"name": "PGLOADBALANCEHOSTS", "source_url": "/docs/16/libpq-envars.html", "description": "PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."}], "manual_html": "
load_balance_hosts
\n

Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:

\n
\n
\n
disable (default)
\n
\n

No load balancing across hosts is performed. Hosts are tried in the order in which they are provided and addresses are tried in the order they are received from DNS or a hosts file.

\n
\n
random
\n
\n

Hosts and addresses are tried in random order. This value is mostly useful when opening multiple connections at the same time, possibly from different machines. This way connections can be load balanced across multiple PostgreSQL servers.

\n

While random load balancing, due to its random nature, will almost never result in a completely uniform distribution, it statistically gets quite close. One important aspect here is that this algorithm uses two levels of random choices: First the hosts will be resolved in random order. Then secondly, before resolving the next host, all resolved addresses for the current host will be tried in random order. This behaviour can skew the amount of connections each node gets greatly in certain cases, for instance when some hosts resolve to more addresses than others. But such a skew can also be used on purpose, e.g. to increase the number of connections a larger server gets by providing its hostname multiple times in the host string.

\n

When using this value it's recommended to also configure a reasonable value for connect_timeout. Because then, if one of the nodes that are used for load balancing is not responding, a new node will be tried.

\n
\n
\n
\n
", "manual_path": "libpq-connect.html#LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "source_option": {"keyword": "load_balance_hosts", "declaration": "\"load_balance_hosts\", \"PGLOADBALANCEHOSTS\", DefaultLoadBalanceHosts, NULL, \"Load-Balance-Hosts\", \"\", 8, offsetof(struct pg_conn, load_balance_hosts)", "environment": "PGLOADBALANCEHOSTS", "source_notes": [], "compiled_default_expression": "DefaultLoadBalanceHosts"}, "comparison_data": {"keyword": "load_balance_hosts", "definition": "Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes: disable (default) No load balancing across hosts is performed. Hosts are tried in the order in which they are provided and addresses are tried in the order they are received from DNS or a hosts file. random Hosts and addresses are tried in random order. This value is mostly useful when opening multiple connections at the same time, possibly from different machines. This way connections can be load balanced across multiple PostgreSQL servers. While random load balancing, due to its random nature, will almost never result in a completely uniform distribution, it statistically gets quite close. One important aspect here is that this algorithm uses two levels of random choices: First the hosts will be resolved in random order. Then secondly, before resolving the next host, all resolved addresses for the current host will be tried in random order. This behaviour can skew the amount of connections each node gets greatly in certain cases, for instance when some hosts resolve to more addresses than others. But such a skew can also be used on purpose, e.g. to increase the number of connections a larger server gets by providing its hostname multiple times in the host string. When using this value it's recommended to also configure a reasonable value for connect_timeout . Because then, if one of the nodes that are used for load balancing is not responding, a new node will be tried.", "documented": true, "environment": "PGLOADBALANCEHOSTS", "default_evidence": [], "compiled_default_expression": "DefaultLoadBalanceHosts"}, "comparison_hash": "4a56aa6394b9330524051722524de4a7e8f8e7120d92113bd663279cd4435c33", "default_evidence": [], "precedence_evidence": ["The following environment variables can be used to select default connection parameter values, which will be used by PQconnectdb , PQsetdbLogin and PQsetdb if no value is directly specified by the calling code. These are useful to avoid hard-coding database connection information into simple client applications, for example.", "Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf . On Microsoft Windows, it is named %APPDATA%\\postgresql\\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified by setting the environment variable PGSERVICEFILE . The system-wide file is named pg_service.conf . By default it is sought in the etc directory of the PostgreSQL installation (use pg_config --sysconfdir to identify this directory precisely). Another directory, but not a different file name, can be specified by setting the environment variable PGSYSCONFDIR .", "Connection parameters obtained from a service file are combined with parameters obtained from other sources. A service file setting overrides the corresponding environment variable, and in turn can be overridden by a value given directly in the connection string. For example, using the above service file, a connection string service=mydb port=5434 will use host somehost , port 5434 , user admin , and other parameters as set by environment variables or built-in defaults."]}, "17": {"facts": [{"label": "Client library", "value": "libpq 17.11"}, {"label": "Manual definition", "value": "Documented"}, {"label": "Source environment fallback", "value": "PGLOADBALANCEHOSTS"}, {"label": "Compiled fallback expression", "value": "DefaultLoadBalanceHosts"}], "tables": [{"key": "environment", "rows": [{"name": {"url": "/docs/17/libpq-envars.html", "text": "PGLOADBALANCEHOSTS"}, "description": "PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."}], "title": "Environment fallback", "columns": [{"key": "name", "label": "Variable"}, {"key": "description", "label": "Documented behavior"}]}], "keyword": "load_balance_hosts", "related": [{"url": "/docs/17/libpq-pgservice.html", "label": "Connection service file"}, {"url": "/docs/17/libpq-pgpass.html", "label": "Password file"}, {"url": "/docs/17/libpq-envars.html", "label": "All libpq environment variables"}], "release": {"ref": "https://ftp.postgresql.org/pub/source/v17.11/postgresql-17.11.tar.bz2", "label": "17.11", "major": "17", "channel": "stable", "manifest": {"pdf": {"A4": {"url": "/files/documentation/pdf/17/postgresql-17-A4.pdf", "bytes": 15521293, "pages": 3099, "sha256": "1991354df0dc89e70ec39328c28988ef8b19c6a93671dab3893650b63e9f4e36", "built_at": "2026-09-26"}, "US": {"url": "/files/documentation/pdf/17/postgresql-17-US.pdf", "bytes": 15398150, "pages": 3270, "sha256": "07696c8f38abf31babf22d2db337093936e7c472d2af36d050b000c49bbcf52c", "built_at": "2026-09-26"}}, "tree": "17", "index": "index.html", "major": "17", "pages": 1143, "release": "17.11", "source_url": "https://ftp.postgresql.org/pub/source/v17.11/postgresql-17.11.tar.bz2", "svg_assets": 3, "source_mode": "en SGML built with pinned official archive", "source_sha256": "dd27f2b3c59e73ed14aa3324901242bf69a032a6347805f274e6260322d42979"}, "revision": "58419c9b0dd42cb34c8d53695bb025a7e582edf55ccd4c5bcb1c2c7c71a37487", "evidence_kind": "English manual and source declarations", "source_sha256": "dd27f2b3c59e73ed14aa3324901242bf69a032a6347805f274e6260322d42979"}, "sources": [{"url": "/docs/17/libpq-connect.html#LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "file": "libpq-connect.html", "label": "17.11 English manual \u00b7 libpq-connect.html", "anchor": "LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "sha256": "7f15cf88e7854d7e92b57bdcb85ce566543eee5783ebc8eb2972cd6aaca8e7a1"}, {"url": "https://ftp.postgresql.org/pub/source/v17.11/postgresql-17.11.tar.bz2", "file": "src/interfaces/libpq/fe-connect.c", "label": "17.11 libpq connection option declarations", "sha256": "9c189446b1b18faf81823636067c9cf9fb01215bdae5b036cc3bb0ebc84971a2", "archive_sha256": "dd27f2b3c59e73ed14aa3324901242bf69a032a6347805f274e6260322d42979"}, {"url": "/docs/17/libpq-envars.html", "file": "libpq-envars.html", "label": "17.11 English manual \u00b7 libpq-envars.html", "anchor": "", "sha256": "48fb76414267a67473ccb901e64320de2e73fb0dc8ade8fcea38edf3628d2c21"}, {"url": "/docs/17/libpq-pgservice.html", "file": "libpq-pgservice.html", "label": "17.11 English manual \u00b7 libpq-pgservice.html", "anchor": "", "sha256": "1447c3836f348d6d0ea59ab68fe17ef604eb913938eed81c1e2cb081a36e2d8d"}], "sections": [{"title": "Default resolution and service-file precedence", "paragraphs": ["The following environment variables can be used to select default connection parameter values, which will be used by PQconnectdb , PQsetdbLogin and PQsetdb if no value is directly specified by the calling code. These are useful to avoid hard-coding database connection information into simple client applications, for example.", "Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf . On Microsoft Windows, it is named %APPDATA%\\postgresql\\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified by setting the environment variable PGSERVICEFILE . The system-wide file is named pg_service.conf . By default it is sought in the etc directory of the PostgreSQL installation (use pg_config --sysconfdir to identify this directory precisely). Another directory, but not a different file name, can be specified by setting the environment variable PGSYSCONFDIR .", "Connection parameters obtained from a service file are combined with parameters obtained from other sources. A service file setting overrides the corresponding environment variable, and in turn can be overridden by a value given directly in the connection string. For example, using the above service file, a connection string service=mydb port=5434 will use host somehost , port 5434 , user admin , and other parameters as set by environment variables or built-in defaults."]}, {"title": "Environment variable evidence", "paragraphs": ["PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."]}], "signature": "load_balance_hosts", "documented": true, "description": ["Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:"], "environment": [{"name": "PGLOADBALANCEHOSTS", "source_url": "/docs/17/libpq-envars.html", "description": "PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."}], "manual_html": "
load_balance_hosts
\n

Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:

\n
\n
\n
disable (default)
\n
\n

No load balancing across hosts is performed. Hosts are tried in the order in which they are provided and addresses are tried in the order they are received from DNS or a hosts file.

\n
\n
random
\n
\n

Hosts and addresses are tried in random order. This value is mostly useful when opening multiple connections at the same time, possibly from different machines. This way connections can be load balanced across multiple PostgreSQL servers.

\n

While random load balancing, due to its random nature, will almost never result in a completely uniform distribution, it statistically gets quite close. One important aspect here is that this algorithm uses two levels of random choices: First the hosts will be resolved in random order. Then secondly, before resolving the next host, all resolved addresses for the current host will be tried in random order. This behaviour can skew the amount of connections each node gets greatly in certain cases, for instance when some hosts resolve to more addresses than others. But such a skew can also be used on purpose, e.g. to increase the number of connections a larger server gets by providing its hostname multiple times in the host string.

\n

When using this value it's recommended to also configure a reasonable value for connect_timeout. Because then, if one of the nodes that are used for load balancing is not responding, a new node will be tried.

\n
\n
\n
\n
", "manual_path": "libpq-connect.html#LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "source_option": {"keyword": "load_balance_hosts", "declaration": "\"load_balance_hosts\", \"PGLOADBALANCEHOSTS\", DefaultLoadBalanceHosts, NULL, \"Load-Balance-Hosts\", \"\", 8, offsetof(struct pg_conn, load_balance_hosts)", "environment": "PGLOADBALANCEHOSTS", "source_notes": [], "compiled_default_expression": "DefaultLoadBalanceHosts"}, "comparison_data": {"keyword": "load_balance_hosts", "definition": "Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes: disable (default) No load balancing across hosts is performed. Hosts are tried in the order in which they are provided and addresses are tried in the order they are received from DNS or a hosts file. random Hosts and addresses are tried in random order. This value is mostly useful when opening multiple connections at the same time, possibly from different machines. This way connections can be load balanced across multiple PostgreSQL servers. While random load balancing, due to its random nature, will almost never result in a completely uniform distribution, it statistically gets quite close. One important aspect here is that this algorithm uses two levels of random choices: First the hosts will be resolved in random order. Then secondly, before resolving the next host, all resolved addresses for the current host will be tried in random order. This behaviour can skew the amount of connections each node gets greatly in certain cases, for instance when some hosts resolve to more addresses than others. But such a skew can also be used on purpose, e.g. to increase the number of connections a larger server gets by providing its hostname multiple times in the host string. When using this value it's recommended to also configure a reasonable value for connect_timeout . Because then, if one of the nodes that are used for load balancing is not responding, a new node will be tried.", "documented": true, "environment": "PGLOADBALANCEHOSTS", "default_evidence": [], "compiled_default_expression": "DefaultLoadBalanceHosts"}, "comparison_hash": "4a56aa6394b9330524051722524de4a7e8f8e7120d92113bd663279cd4435c33", "default_evidence": [], "precedence_evidence": ["The following environment variables can be used to select default connection parameter values, which will be used by PQconnectdb , PQsetdbLogin and PQsetdb if no value is directly specified by the calling code. These are useful to avoid hard-coding database connection information into simple client applications, for example.", "Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf . On Microsoft Windows, it is named %APPDATA%\\postgresql\\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified by setting the environment variable PGSERVICEFILE . The system-wide file is named pg_service.conf . By default it is sought in the etc directory of the PostgreSQL installation (use pg_config --sysconfdir to identify this directory precisely). Another directory, but not a different file name, can be specified by setting the environment variable PGSYSCONFDIR .", "Connection parameters obtained from a service file are combined with parameters obtained from other sources. A service file setting overrides the corresponding environment variable, and in turn can be overridden by a value given directly in the connection string. For example, using the above service file, a connection string service=mydb port=5434 will use host somehost , port 5434 , user admin , and other parameters as set by environment variables or built-in defaults."]}, "18": {"facts": [{"label": "Client library", "value": "libpq 18.6"}, {"label": "Manual definition", "value": "Documented"}, {"label": "Source environment fallback", "value": "PGLOADBALANCEHOSTS"}, {"label": "Compiled fallback expression", "value": "DefaultLoadBalanceHosts"}], "tables": [{"key": "environment", "rows": [{"name": {"url": "/docs/18/libpq-envars.html", "text": "PGLOADBALANCEHOSTS"}, "description": "PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."}], "title": "Environment fallback", "columns": [{"key": "name", "label": "Variable"}, {"key": "description", "label": "Documented behavior"}]}], "keyword": "load_balance_hosts", "related": [{"url": "/docs/18/libpq-pgservice.html", "label": "Connection service file"}, {"url": "/docs/18/libpq-pgpass.html", "label": "Password file"}, {"url": "/docs/18/libpq-envars.html", "label": "All libpq environment variables"}], "release": {"ref": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "label": "18.6", "major": "18", "channel": "stable", "manifest": {"pdf": {"A4": {"url": "/files/documentation/pdf/18/postgresql-18-A4.pdf", "bytes": 15865106, "pages": 3154, "sha256": "19512c405da53f9f7fcf0abba359223aa65f021be025bf3411381918f92e3190", "built_at": "2026-09-26"}, "US": {"url": "/files/documentation/pdf/18/postgresql-18-US.pdf", "bytes": 15748059, "pages": 3328, "sha256": "facbe6c229e598b872d3d98bef53308f46e06746006fa4590de9a7de9dd46319", "built_at": "2026-09-26"}}, "tree": "18", "index": "index.html", "major": "18", "pages": 1148, "release": "18.6", "source_url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "svg_assets": 3, "source_mode": "en SGML built with pinned official archive", "source_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, "revision": "ee8d1a3612338fd9adf250730cb640fcc5233b5491337cc00a316a44e3a0b9f8", "evidence_kind": "English manual and source declarations", "source_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, "sources": [{"url": "/docs/18/libpq-connect.html#LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "file": "libpq-connect.html", "label": "18.6 English manual \u00b7 libpq-connect.html", "anchor": "LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "sha256": "c26a7fc3dcda6066cfe540641ae2690faf3d3c03277f30b4dfc2328ab45c212f"}, {"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "file": "src/interfaces/libpq/fe-connect.c", "label": "18.6 libpq connection option declarations", "sha256": "44a6e386cbfd67ebe768d6ef5493098119c2e6b4796239d53e5ed7b122b206a5", "archive_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, {"url": "/docs/18/libpq-envars.html", "file": "libpq-envars.html", "label": "18.6 English manual \u00b7 libpq-envars.html", "anchor": "", "sha256": "d64db73f3d48127bb984a5f775e77b7bcca2ba4bd218333cf24a45fcdd7c4363"}, {"url": "/docs/18/libpq-pgservice.html", "file": "libpq-pgservice.html", "label": "18.6 English manual \u00b7 libpq-pgservice.html", "anchor": "", "sha256": "6035a3f0ee1d0fd80db5bf58834390b884eecd23206659bdf6f07560deea5aa7"}], "sections": [{"title": "Default resolution and service-file precedence", "paragraphs": ["The following environment variables can be used to select default connection parameter values, which will be used by PQconnectdb , PQsetdbLogin and PQsetdb if no value is directly specified by the calling code. These are useful to avoid hard-coding database connection information into simple client applications, for example.", "Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf . On Microsoft Windows, it is named %APPDATA%\\postgresql\\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified by setting the environment variable PGSERVICEFILE . The system-wide file is named pg_service.conf . By default it is sought in the etc directory of the PostgreSQL installation (use pg_config --sysconfdir to identify this directory precisely). Another directory, but not a different file name, can be specified by setting the environment variable PGSYSCONFDIR .", "Connection parameters obtained from a service file are combined with parameters obtained from other sources. A service file setting overrides the corresponding environment variable, and in turn can be overridden by a value given directly in the connection string. For example, using the above service file, a connection string service=mydb port=5434 will use host somehost , port 5434 , user admin , and other parameters as set by environment variables or built-in defaults."]}, {"title": "Environment variable evidence", "paragraphs": ["PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."]}], "signature": "load_balance_hosts", "documented": true, "description": ["Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:"], "environment": [{"name": "PGLOADBALANCEHOSTS", "source_url": "/docs/18/libpq-envars.html", "description": "PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."}], "manual_html": "
load_balance_hosts
\n

Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:

\n
\n
\n
disable (default)
\n
\n

No load balancing across hosts is performed. Hosts are tried in the order in which they are provided and addresses are tried in the order they are received from DNS or a hosts file.

\n
\n
random
\n
\n

Hosts and addresses are tried in random order. This value is mostly useful when opening multiple connections at the same time, possibly from different machines. This way connections can be load balanced across multiple PostgreSQL servers.

\n

While random load balancing, due to its random nature, will almost never result in a completely uniform distribution, it statistically gets quite close. One important aspect here is that this algorithm uses two levels of random choices: First the hosts will be resolved in random order. Then secondly, before resolving the next host, all resolved addresses for the current host will be tried in random order. This behaviour can skew the amount of connections each node gets greatly in certain cases, for instance when some hosts resolve to more addresses than others. But such a skew can also be used on purpose, e.g. to increase the number of connections a larger server gets by providing its hostname multiple times in the host string.

\n

When using this value it's recommended to also configure a reasonable value for connect_timeout. Because then, if one of the nodes that are used for load balancing is not responding, a new node will be tried.

\n
\n
\n
\n
", "manual_path": "libpq-connect.html#LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "source_option": {"keyword": "load_balance_hosts", "declaration": "\"load_balance_hosts\", \"PGLOADBALANCEHOSTS\", DefaultLoadBalanceHosts, NULL, \"Load-Balance-Hosts\", \"\", 8, offsetof(struct pg_conn, load_balance_hosts)", "environment": "PGLOADBALANCEHOSTS", "source_notes": [], "compiled_default_expression": "DefaultLoadBalanceHosts"}, "comparison_data": {"keyword": "load_balance_hosts", "definition": "Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes: disable (default) No load balancing across hosts is performed. Hosts are tried in the order in which they are provided and addresses are tried in the order they are received from DNS or a hosts file. random Hosts and addresses are tried in random order. This value is mostly useful when opening multiple connections at the same time, possibly from different machines. This way connections can be load balanced across multiple PostgreSQL servers. While random load balancing, due to its random nature, will almost never result in a completely uniform distribution, it statistically gets quite close. One important aspect here is that this algorithm uses two levels of random choices: First the hosts will be resolved in random order. Then secondly, before resolving the next host, all resolved addresses for the current host will be tried in random order. This behaviour can skew the amount of connections each node gets greatly in certain cases, for instance when some hosts resolve to more addresses than others. But such a skew can also be used on purpose, e.g. to increase the number of connections a larger server gets by providing its hostname multiple times in the host string. When using this value it's recommended to also configure a reasonable value for connect_timeout . Because then, if one of the nodes that are used for load balancing is not responding, a new node will be tried.", "documented": true, "environment": "PGLOADBALANCEHOSTS", "default_evidence": [], "compiled_default_expression": "DefaultLoadBalanceHosts"}, "comparison_hash": "4a56aa6394b9330524051722524de4a7e8f8e7120d92113bd663279cd4435c33", "default_evidence": [], "precedence_evidence": ["The following environment variables can be used to select default connection parameter values, which will be used by PQconnectdb , PQsetdbLogin and PQsetdb if no value is directly specified by the calling code. These are useful to avoid hard-coding database connection information into simple client applications, for example.", "Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf . On Microsoft Windows, it is named %APPDATA%\\postgresql\\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified by setting the environment variable PGSERVICEFILE . The system-wide file is named pg_service.conf . By default it is sought in the etc directory of the PostgreSQL installation (use pg_config --sysconfdir to identify this directory precisely). Another directory, but not a different file name, can be specified by setting the environment variable PGSYSCONFDIR .", "Connection parameters obtained from a service file are combined with parameters obtained from other sources. A service file setting overrides the corresponding environment variable, and in turn can be overridden by a value given directly in the connection string. For example, using the above service file, a connection string service=mydb port=5434 will use host somehost , port 5434 , user admin , and other parameters as set by environment variables or built-in defaults."]}, "19": {"facts": [{"label": "Client library", "value": "libpq 19beta4"}, {"label": "Manual definition", "value": "Documented"}, {"label": "Source environment fallback", "value": "PGLOADBALANCEHOSTS"}, {"label": "Compiled fallback expression", "value": "DefaultLoadBalanceHosts"}], "tables": [{"key": "environment", "rows": [{"name": {"url": "/docs/19/libpq-envars.html", "text": "PGLOADBALANCEHOSTS"}, "description": "PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."}], "title": "Environment fallback", "columns": [{"key": "name", "label": "Variable"}, {"key": "description", "label": "Documented behavior"}]}], "keyword": "load_balance_hosts", "related": [{"url": "/docs/19/libpq-pgservice.html", "label": "Connection service file"}, {"url": "/docs/19/libpq-pgpass.html", "label": "Password file"}, {"url": "/docs/19/libpq-envars.html", "label": "All libpq environment variables"}], "release": {"ref": "https://ftp.postgresql.org/pub/source/v19beta4/postgresql-19beta4.tar.bz2", "label": "19beta4", "major": "19", "channel": "preview", "manifest": {"pdf": {"A4": {"url": "/files/documentation/pdf/19/postgresql-19-A4.pdf", "bytes": 16064841, "pages": 3052, "sha256": "4dd099e4125c591128fc5f3ebd02178dc24781f9e5ae629f96d67c4c8547427b", "built_at": "2026-09-26"}, "US": {"url": "/files/documentation/pdf/19/postgresql-19-US.pdf", "bytes": 15974616, "pages": 3225, "sha256": "61971fa857f0956d47341a0388fa6af9ae10acf691d4b2fc009007d384b0342b", "built_at": "2026-09-26"}}, "tree": "19", "index": "index.html", "major": "19", "pages": 1155, "release": "19beta4", "source_url": "https://ftp.postgresql.org/pub/source/v19beta4/postgresql-19beta4.tar.bz2", "svg_assets": 5, "source_mode": "en SGML built with pinned official archive", "source_sha256": "83157ee9c599d03b2f7a3d73ef3a56ec24e0e79cc2b3501a64d1364f56398c86"}, "revision": "1bbbbf4133d426f0e4304010688d2984c30fb67df0cc3a61b3e37eb3f6f37833", "evidence_kind": "English manual and source declarations", "source_sha256": "83157ee9c599d03b2f7a3d73ef3a56ec24e0e79cc2b3501a64d1364f56398c86"}, "sources": [{"url": "/docs/19/libpq-connect.html#LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "file": "libpq-connect.html", "label": "19beta4 English manual \u00b7 libpq-connect.html", "anchor": "LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "sha256": "14917417235a95d969bf3642c347dea7ae548c5f73b0dd00991a580ebcfbb47e"}, {"url": "https://ftp.postgresql.org/pub/source/v19beta4/postgresql-19beta4.tar.bz2", "file": "src/interfaces/libpq/fe-connect.c", "label": "19beta4 libpq connection option declarations", "sha256": "ae8005372c570ff47a4922c942238653a034f01f9db40c9e0f57cb48915ffd98", "archive_sha256": "83157ee9c599d03b2f7a3d73ef3a56ec24e0e79cc2b3501a64d1364f56398c86"}, {"url": "/docs/19/libpq-envars.html", "file": "libpq-envars.html", "label": "19beta4 English manual \u00b7 libpq-envars.html", "anchor": "", "sha256": "d8f0afee19bae6323942ea5415649fbd66e3880fe8c8415350fcf3915f7c7047"}, {"url": "/docs/19/libpq-pgservice.html", "file": "libpq-pgservice.html", "label": "19beta4 English manual \u00b7 libpq-pgservice.html", "anchor": "", "sha256": "4c858fe55701d703cc00e7adf55eeac09cafcfdc37929b8e23ccf8ba42af9f98"}], "sections": [{"title": "Default resolution and service-file precedence", "paragraphs": ["The following environment variables can be used to select default connection parameter values, which will be used by PQconnectdb , PQsetdbLogin and PQsetdb if no value is directly specified by the calling code. These are useful to avoid hard-coding database connection information into simple client applications, for example.", "Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf . On Microsoft Windows, it is named %APPDATA%\\postgresql\\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified using the servicefile key word in a libpq connection string or by setting the environment variable PGSERVICEFILE . The system-wide file is named pg_service.conf . By default it is sought in the etc directory of the PostgreSQL installation (use pg_config --sysconfdir to identify this directory precisely). Another directory, but not a different file name, can be specified by setting the environment variable PGSYSCONFDIR .", "Connection parameters obtained from a service file are combined with parameters obtained from other sources. A service file setting overrides the corresponding environment variable, and in turn can be overridden by a value given directly in the connection string. For example, using the above service file, a connection string service=mydb port=5434 will use host somehost , port 5434 , user admin , and other parameters as set by environment variables or built-in defaults."]}, {"title": "Environment variable evidence", "paragraphs": ["PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."]}], "signature": "load_balance_hosts", "documented": true, "description": ["Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:"], "environment": [{"name": "PGLOADBALANCEHOSTS", "source_url": "/docs/19/libpq-envars.html", "description": "PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."}], "manual_html": "
load_balance_hosts
\n

Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:

\n
\n
\n
disable (default)
\n
\n

No load balancing across hosts is performed. Hosts are tried in the order in which they are provided and addresses are tried in the order they are received from DNS or a hosts file.

\n
\n
random
\n
\n

Hosts and addresses are tried in random order. This value is mostly useful when opening multiple connections at the same time, possibly from different machines. This way connections can be load balanced across multiple PostgreSQL servers.

\n

While random load balancing, due to its random nature, will almost never result in a completely uniform distribution, it statistically gets quite close. One important aspect here is that this algorithm uses two levels of random choices: First the hosts will be resolved in random order. Then secondly, before resolving the next host, all resolved addresses for the current host will be tried in random order. This behaviour can skew the amount of connections each node gets greatly in certain cases, for instance when some hosts resolve to more addresses than others. But such a skew can also be used on purpose, e.g. to increase the number of connections a larger server gets by providing its hostname multiple times in the host string.

\n

When using this value it's recommended to also configure a reasonable value for connect_timeout. Because then, if one of the nodes that are used for load balancing is not responding, a new node will be tried.

\n
\n
\n
\n
", "manual_path": "libpq-connect.html#LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "source_option": {"keyword": "load_balance_hosts", "declaration": "\"load_balance_hosts\", \"PGLOADBALANCEHOSTS\", DefaultLoadBalanceHosts, NULL, \"Load-Balance-Hosts\", \"\", 8, offsetof(struct pg_conn, load_balance_hosts)", "environment": "PGLOADBALANCEHOSTS", "source_notes": [], "compiled_default_expression": "DefaultLoadBalanceHosts"}, "comparison_data": {"keyword": "load_balance_hosts", "definition": "Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes: disable (default) No load balancing across hosts is performed. Hosts are tried in the order in which they are provided and addresses are tried in the order they are received from DNS or a hosts file. random Hosts and addresses are tried in random order. This value is mostly useful when opening multiple connections at the same time, possibly from different machines. This way connections can be load balanced across multiple PostgreSQL servers. While random load balancing, due to its random nature, will almost never result in a completely uniform distribution, it statistically gets quite close. One important aspect here is that this algorithm uses two levels of random choices: First the hosts will be resolved in random order. Then secondly, before resolving the next host, all resolved addresses for the current host will be tried in random order. This behaviour can skew the amount of connections each node gets greatly in certain cases, for instance when some hosts resolve to more addresses than others. But such a skew can also be used on purpose, e.g. to increase the number of connections a larger server gets by providing its hostname multiple times in the host string. When using this value it's recommended to also configure a reasonable value for connect_timeout . Because then, if one of the nodes that are used for load balancing is not responding, a new node will be tried.", "documented": true, "environment": "PGLOADBALANCEHOSTS", "default_evidence": [], "compiled_default_expression": "DefaultLoadBalanceHosts"}, "comparison_hash": "4a56aa6394b9330524051722524de4a7e8f8e7120d92113bd663279cd4435c33", "default_evidence": [], "precedence_evidence": ["The following environment variables can be used to select default connection parameter values, which will be used by PQconnectdb , PQsetdbLogin and PQsetdb if no value is directly specified by the calling code. These are useful to avoid hard-coding database connection information into simple client applications, for example.", "Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf . On Microsoft Windows, it is named %APPDATA%\\postgresql\\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified using the servicefile key word in a libpq connection string or by setting the environment variable PGSERVICEFILE . The system-wide file is named pg_service.conf . By default it is sought in the etc directory of the PostgreSQL installation (use pg_config --sysconfdir to identify this directory precisely). Another directory, but not a different file name, can be specified by setting the environment variable PGSYSCONFDIR .", "Connection parameters obtained from a service file are combined with parameters obtained from other sources. A service file setting overrides the corresponding environment variable, and in turn can be overridden by a value given directly in the connection string. For example, using the above service file, a connection string service=mydb port=5434 will use host somehost , port 5434 , user admin , and other parameters as set by environment variables or built-in defaults."]}, "20": {"facts": [{"label": "Client library", "value": "libpq 20devel"}, {"label": "Manual definition", "value": "Documented"}, {"label": "Source environment fallback", "value": "PGLOADBALANCEHOSTS"}, {"label": "Compiled fallback expression", "value": "DefaultLoadBalanceHosts"}], "tables": [{"key": "environment", "rows": [{"name": {"url": "/docs/devel/libpq-envars.html", "text": "PGLOADBALANCEHOSTS"}, "description": "PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."}], "title": "Environment fallback", "columns": [{"key": "name", "label": "Variable"}, {"key": "description", "label": "Documented behavior"}]}], "keyword": "load_balance_hosts", "related": [{"url": "/docs/devel/libpq-pgservice.html", "label": "Connection service file"}, {"url": "/docs/devel/libpq-pgpass.html", "label": "Password file"}, {"url": "/docs/devel/libpq-envars.html", "label": "All libpq environment variables"}], "release": {"ref": "https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2", "label": "20devel", "major": "20", "channel": "devel", "manifest": {"pdf": {"A4": {"url": "/files/documentation/pdf/20/postgresql-20-A4.pdf", "bytes": 16030631, "pages": 3052, "sha256": "bd5d82c0ce38fc18f92a0447818a91a193a261776bca1c37564bf9a683e177d0", "built_at": "2026-09-28"}, "US": {"url": "/files/documentation/pdf/20/postgresql-20-US.pdf", "bytes": 15936613, "pages": 3223, "sha256": "d97d9e0db479a02f4234b175f50fcad70c3661619afc8d6df9b9437882e3c299", "built_at": "2026-09-28"}}, "tree": "0", "index": "index.html", "major": "20", "pages": 1156, "release": "20devel", "source_url": "https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2", "svg_assets": 6, "source_mode": "en SGML built with pinned official archive", "source_sha256": "4d3346909b201ac1648232cf290462a7070c119326f56196f1f0253ed80fae41", "source_snapshot_utc": "26-Sep-2026 20:22"}, "revision": "2eba5e0fd4c3bffb2803247b6cd537878e9d6ee5a6dfbe3c50ece8b421b80918", "evidence_kind": "English manual and source declarations", "source_sha256": "4d3346909b201ac1648232cf290462a7070c119326f56196f1f0253ed80fae41"}, "sources": [{"url": "/docs/devel/libpq-connect.html#LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "file": "libpq-connect.html", "label": "20devel English manual \u00b7 libpq-connect.html", "anchor": "LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "sha256": "eeb28ce798c0f99c3581400b4baaae7687ee5d4176fcb9f5d2fd28809282d48f"}, {"url": "https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2", "file": "src/interfaces/libpq/fe-connect.c", "label": "20devel libpq connection option declarations", "sha256": "d6eab6e2f37054b32a7ee7039b53beae603316f8ec3f0a14716061e042fc4aa1", "archive_sha256": "4d3346909b201ac1648232cf290462a7070c119326f56196f1f0253ed80fae41"}, {"url": "/docs/devel/libpq-envars.html", "file": "libpq-envars.html", "label": "20devel English manual \u00b7 libpq-envars.html", "anchor": "", "sha256": "7c49cf204e26ea86654491db5ea06c4f558c670e2e60a60b1dbf708ce682accc"}, {"url": "/docs/devel/libpq-pgservice.html", "file": "libpq-pgservice.html", "label": "20devel English manual \u00b7 libpq-pgservice.html", "anchor": "", "sha256": "a1ccd63a6e307a5541d58eabd57be5b467dff2480770838ec9b6a59a3ef110dc"}], "sections": [{"title": "Default resolution and service-file precedence", "paragraphs": ["The following environment variables can be used to select default connection parameter values, which will be used by PQconnectdb , PQsetdbLogin and PQsetdb if no value is directly specified by the calling code. These are useful to avoid hard-coding database connection information into simple client applications, for example.", "Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf . On Microsoft Windows, it is named %APPDATA%\\postgresql\\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified using the servicefile key word in a libpq connection string or by setting the environment variable PGSERVICEFILE . The system-wide file is named pg_service.conf . By default it is sought in the etc directory of the PostgreSQL installation (use pg_config --sysconfdir to identify this directory precisely). Another directory, but not a different file name, can be specified by setting the environment variable PGSYSCONFDIR .", "Connection parameters obtained from a service file are combined with parameters obtained from other sources. A service file setting overrides the corresponding environment variable, and in turn can be overridden by a value given directly in the connection string. For example, using the above service file, a connection string service=mydb port=5434 will use host somehost , port 5434 , user admin , and other parameters as set by environment variables or built-in defaults."]}, {"title": "Environment variable evidence", "paragraphs": ["PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."]}], "signature": "load_balance_hosts", "documented": true, "description": ["Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:"], "environment": [{"name": "PGLOADBALANCEHOSTS", "source_url": "/docs/devel/libpq-envars.html", "description": "PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."}], "manual_html": "
load_balance_hosts
\n

Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:

\n
\n
\n
disable (default)
\n
\n

No load balancing across hosts is performed. Hosts are tried in the order in which they are provided and addresses are tried in the order they are received from DNS or a hosts file.

\n
\n
random
\n
\n

Hosts and addresses are tried in random order. This value is mostly useful when opening multiple connections at the same time, possibly from different machines. This way connections can be load balanced across multiple PostgreSQL servers.

\n

While random load balancing, due to its random nature, will almost never result in a completely uniform distribution, it statistically gets quite close. One important aspect here is that this algorithm uses two levels of random choices: First the hosts will be resolved in random order. Then secondly, before resolving the next host, all resolved addresses for the current host will be tried in random order. This behaviour can skew the amount of connections each node gets greatly in certain cases, for instance when some hosts resolve to more addresses than others. But such a skew can also be used on purpose, e.g. to increase the number of connections a larger server gets by providing its hostname multiple times in the host string.

\n

When using this value it's recommended to also configure a reasonable value for connect_timeout. Because then, if one of the nodes that are used for load balancing is not responding, a new node will be tried.

\n
\n
\n
\n
", "manual_path": "libpq-connect.html#LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "source_option": {"keyword": "load_balance_hosts", "declaration": "\"load_balance_hosts\", \"PGLOADBALANCEHOSTS\", DefaultLoadBalanceHosts, NULL, \"Load-Balance-Hosts\", \"\", 8, offsetof(struct pg_conn, load_balance_hosts)", "environment": "PGLOADBALANCEHOSTS", "source_notes": [], "compiled_default_expression": "DefaultLoadBalanceHosts"}, "comparison_data": {"keyword": "load_balance_hosts", "definition": "Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes: disable (default) No load balancing across hosts is performed. Hosts are tried in the order in which they are provided and addresses are tried in the order they are received from DNS or a hosts file. random Hosts and addresses are tried in random order. This value is mostly useful when opening multiple connections at the same time, possibly from different machines. This way connections can be load balanced across multiple PostgreSQL servers. While random load balancing, due to its random nature, will almost never result in a completely uniform distribution, it statistically gets quite close. One important aspect here is that this algorithm uses two levels of random choices: First the hosts will be resolved in random order. Then secondly, before resolving the next host, all resolved addresses for the current host will be tried in random order. This behaviour can skew the amount of connections each node gets greatly in certain cases, for instance when some hosts resolve to more addresses than others. But such a skew can also be used on purpose, e.g. to increase the number of connections a larger server gets by providing its hostname multiple times in the host string. When using this value it's recommended to also configure a reasonable value for connect_timeout . Because then, if one of the nodes that are used for load balancing is not responding, a new node will be tried.", "documented": true, "environment": "PGLOADBALANCEHOSTS", "default_evidence": [], "compiled_default_expression": "DefaultLoadBalanceHosts"}, "comparison_hash": "4a56aa6394b9330524051722524de4a7e8f8e7120d92113bd663279cd4435c33", "default_evidence": [], "precedence_evidence": ["The following environment variables can be used to select default connection parameter values, which will be used by PQconnectdb , PQsetdbLogin and PQsetdb if no value is directly specified by the calling code. These are useful to avoid hard-coding database connection information into simple client applications, for example.", "Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf . On Microsoft Windows, it is named %APPDATA%\\postgresql\\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified using the servicefile key word in a libpq connection string or by setting the environment variable PGSERVICEFILE . The system-wide file is named pg_service.conf . By default it is sought in the etc directory of the PostgreSQL installation (use pg_config --sysconfdir to identify this directory precisely). Another directory, but not a different file name, can be specified by setting the environment variable PGSYSCONFDIR .", "Connection parameters obtained from a service file are combined with parameters obtained from other sources. A service file setting overrides the corresponding environment variable, and in turn can be overridden by a value given directly in the connection string. For example, using the above service file, a connection string service=mydb port=5434 will use host somehost , port 5434 , user admin , and other parameters as set by environment variables or built-in defaults."]}}}, "snapshot": {"facts": [{"label": "Client library", "value": "libpq 18.6"}, {"label": "Manual definition", "value": "Documented"}, {"label": "Source environment fallback", "value": "PGLOADBALANCEHOSTS"}, {"label": "Compiled fallback expression", "value": "DefaultLoadBalanceHosts"}], "tables": [{"key": "environment", "rows": [{"name": {"url": "/docs/18/libpq-envars.html", "text": "PGLOADBALANCEHOSTS"}, "description": "PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."}], "title": "Environment fallback", "columns": [{"key": "name", "label": "Variable"}, {"key": "description", "label": "Documented behavior"}]}], "keyword": "load_balance_hosts", "related": [{"url": "/docs/18/libpq-pgservice.html", "label": "Connection service file"}, {"url": "/docs/18/libpq-pgpass.html", "label": "Password file"}, {"url": "/docs/18/libpq-envars.html", "label": "All libpq environment variables"}], "release": {"ref": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "label": "18.6", "major": "18", "channel": "stable", "manifest": {"pdf": {"A4": {"url": "/files/documentation/pdf/18/postgresql-18-A4.pdf", "bytes": 15865106, "pages": 3154, "sha256": "19512c405da53f9f7fcf0abba359223aa65f021be025bf3411381918f92e3190", "built_at": "2026-09-26"}, "US": {"url": "/files/documentation/pdf/18/postgresql-18-US.pdf", "bytes": 15748059, "pages": 3328, "sha256": "facbe6c229e598b872d3d98bef53308f46e06746006fa4590de9a7de9dd46319", "built_at": "2026-09-26"}}, "tree": "18", "index": "index.html", "major": "18", "pages": 1148, "release": "18.6", "source_url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "svg_assets": 3, "source_mode": "en SGML built with pinned official archive", "source_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, "revision": "ee8d1a3612338fd9adf250730cb640fcc5233b5491337cc00a316a44e3a0b9f8", "evidence_kind": "English manual and source declarations", "source_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, "sources": [{"url": "/docs/18/libpq-connect.html#LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "file": "libpq-connect.html", "label": "18.6 English manual \u00b7 libpq-connect.html", "anchor": "LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "sha256": "c26a7fc3dcda6066cfe540641ae2690faf3d3c03277f30b4dfc2328ab45c212f"}, {"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "file": "src/interfaces/libpq/fe-connect.c", "label": "18.6 libpq connection option declarations", "sha256": "44a6e386cbfd67ebe768d6ef5493098119c2e6b4796239d53e5ed7b122b206a5", "archive_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, {"url": "/docs/18/libpq-envars.html", "file": "libpq-envars.html", "label": "18.6 English manual \u00b7 libpq-envars.html", "anchor": "", "sha256": "d64db73f3d48127bb984a5f775e77b7bcca2ba4bd218333cf24a45fcdd7c4363"}, {"url": "/docs/18/libpq-pgservice.html", "file": "libpq-pgservice.html", "label": "18.6 English manual \u00b7 libpq-pgservice.html", "anchor": "", "sha256": "6035a3f0ee1d0fd80db5bf58834390b884eecd23206659bdf6f07560deea5aa7"}], "sections": [{"title": "Default resolution and service-file precedence", "paragraphs": ["The following environment variables can be used to select default connection parameter values, which will be used by PQconnectdb , PQsetdbLogin and PQsetdb if no value is directly specified by the calling code. These are useful to avoid hard-coding database connection information into simple client applications, for example.", "Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf . On Microsoft Windows, it is named %APPDATA%\\postgresql\\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified by setting the environment variable PGSERVICEFILE . The system-wide file is named pg_service.conf . By default it is sought in the etc directory of the PostgreSQL installation (use pg_config --sysconfdir to identify this directory precisely). Another directory, but not a different file name, can be specified by setting the environment variable PGSYSCONFDIR .", "Connection parameters obtained from a service file are combined with parameters obtained from other sources. A service file setting overrides the corresponding environment variable, and in turn can be overridden by a value given directly in the connection string. For example, using the above service file, a connection string service=mydb port=5434 will use host somehost , port 5434 , user admin , and other parameters as set by environment variables or built-in defaults."]}, {"title": "Environment variable evidence", "paragraphs": ["PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."]}], "signature": "load_balance_hosts", "documented": true, "description": ["Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:"], "environment": [{"name": "PGLOADBALANCEHOSTS", "source_url": "/docs/18/libpq-envars.html", "description": "PGLOADBALANCEHOSTS behaves the same as the load_balance_hosts connection parameter."}], "manual_html": "
load_balance_hosts
\n

Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes:

\n
\n
\n
disable (default)
\n
\n

No load balancing across hosts is performed. Hosts are tried in the order in which they are provided and addresses are tried in the order they are received from DNS or a hosts file.

\n
\n
random
\n
\n

Hosts and addresses are tried in random order. This value is mostly useful when opening multiple connections at the same time, possibly from different machines. This way connections can be load balanced across multiple PostgreSQL servers.

\n

While random load balancing, due to its random nature, will almost never result in a completely uniform distribution, it statistically gets quite close. One important aspect here is that this algorithm uses two levels of random choices: First the hosts will be resolved in random order. Then secondly, before resolving the next host, all resolved addresses for the current host will be tried in random order. This behaviour can skew the amount of connections each node gets greatly in certain cases, for instance when some hosts resolve to more addresses than others. But such a skew can also be used on purpose, e.g. to increase the number of connections a larger server gets by providing its hostname multiple times in the host string.

\n

When using this value it's recommended to also configure a reasonable value for connect_timeout. Because then, if one of the nodes that are used for load balancing is not responding, a new node will be tried.

\n
\n
\n
\n
", "manual_path": "libpq-connect.html#LIBPQ-CONNECT-LOAD-BALANCE-HOSTS", "source_option": {"keyword": "load_balance_hosts", "declaration": "\"load_balance_hosts\", \"PGLOADBALANCEHOSTS\", DefaultLoadBalanceHosts, NULL, \"Load-Balance-Hosts\", \"\", 8, offsetof(struct pg_conn, load_balance_hosts)", "environment": "PGLOADBALANCEHOSTS", "source_notes": [], "compiled_default_expression": "DefaultLoadBalanceHosts"}, "comparison_data": {"keyword": "load_balance_hosts", "definition": "Controls the order in which the client tries to connect to the available hosts and addresses. Once a connection attempt is successful no other hosts and addresses will be tried. This parameter is typically used in combination with multiple host names or a DNS record that returns multiple IPs. This parameter can be used in combination with target_session_attrs to, for example, load balance over standby servers only. Once successfully connected, subsequent queries on the returned connection will all be sent to the same server. There are currently two modes: disable (default) No load balancing across hosts is performed. Hosts are tried in the order in which they are provided and addresses are tried in the order they are received from DNS or a hosts file. random Hosts and addresses are tried in random order. This value is mostly useful when opening multiple connections at the same time, possibly from different machines. This way connections can be load balanced across multiple PostgreSQL servers. While random load balancing, due to its random nature, will almost never result in a completely uniform distribution, it statistically gets quite close. One important aspect here is that this algorithm uses two levels of random choices: First the hosts will be resolved in random order. Then secondly, before resolving the next host, all resolved addresses for the current host will be tried in random order. This behaviour can skew the amount of connections each node gets greatly in certain cases, for instance when some hosts resolve to more addresses than others. But such a skew can also be used on purpose, e.g. to increase the number of connections a larger server gets by providing its hostname multiple times in the host string. When using this value it's recommended to also configure a reasonable value for connect_timeout . Because then, if one of the nodes that are used for load balancing is not responding, a new node will be tried.", "documented": true, "environment": "PGLOADBALANCEHOSTS", "default_evidence": [], "compiled_default_expression": "DefaultLoadBalanceHosts"}, "comparison_hash": "4a56aa6394b9330524051722524de4a7e8f8e7120d92113bd663279cd4435c33", "default_evidence": [], "precedence_evidence": ["The following environment variables can be used to select default connection parameter values, which will be used by PQconnectdb , PQsetdbLogin and PQsetdb if no value is directly specified by the calling code. These are useful to avoid hard-coding database connection information into simple client applications, for example.", "Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf . On Microsoft Windows, it is named %APPDATA%\\postgresql\\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified by setting the environment variable PGSERVICEFILE . The system-wide file is named pg_service.conf . By default it is sought in the etc directory of the PostgreSQL installation (use pg_config --sysconfdir to identify this directory precisely). Another directory, but not a different file name, can be specified by setting the environment variable PGSYSCONFDIR .", "Connection parameters obtained from a service file are combined with parameters obtained from other sources. A service file setting overrides the corresponding environment variable, and in turn can be overridden by a value given directly in the connection string. For example, using the above service file, a connection string service=mydb port=5434 will use host somehost , port 5434 , user admin , and other parameters as set by environment variables or built-in defaults."]}, "comparison": {"left": "17", "right": "18", "status": "unchanged", "diff": ""}}