Обсуждение: pg_isready bug
We are using Postgres in docker. And problem with pg_isready was found.
Please, look:
root@29243fe45836:/# psql -U postgres
psql (11.6 (Debian 11.6-1.pgdg90+1))
Type "help" for help.
postgres=# \l+
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges | Size | Tablespace | Description
-----------+----------+----------+------------+------------+-----------------------+---------+------------+--------------------------------------------
internal | postgres | UTF8 | en_US.utf8 | en_US.utf8 | | 12 MB | pg_default |
postgres | postgres | UTF8 | en_US.utf8 | en_US.utf8 | | 7669 kB | pg_default | default administrative connection database
template0 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres +| 7529 kB | pg_default | unmodifiable empty database
| | | | | postgres=CTc/postgres | | |
template1 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres +| 7529 kB | pg_default | default template for new databases
| | | | | postgres=CTc/postgres | | |
(4 rows)
postgres=# exit
root@29243fe45836:/# pg_isready -d 123456 -h localhost -p 5432 -U postgres # the DB 123456 doesn't exist
localhost:5432 - accepting connections # but it shows all is good
root@29243fe45836:/# echo $?
0
root@29243fe45836:/# pg_isready -d internal -h localhost -p 5432 -U postgres # the DB internal doesn't exist
localhost:5432 - accepting connections # looks good
root@29243fe45836:/# echo $?
0
The exitcodes of pg_isready if the DB doesn't exist and if exists are the same.
It will be better to exit with non null exitcode if pg_isready can't connect to absent db or using incorrect user.
Best regards,
Aliaksei Hunosau, DevOps engineer |
Hello,
> root@29243fe45836:/# pg_isready -d 123456 -h localhost -p 5432 -U postgres # the DB 123456 doesn't exist
> localhost:5432 - accepting connections # but it shows all is good
> root@29243fe45836:/# echo $?
> 0
I can confirm, but I'm afraid it is a feature.
The server *is* indeed accepting connections… it does not say that the
connection with the parameters you supplied worked.
The feature relies on "PQpingParams" function which states the following
somehow strange sentence:
"It is not necessary to supply correct user name, password, or database
name values to obtain the server status; however, if incorrect values are
provided, the server will log a failed connection attempt."
The same occurs with a non existing user (-U).
Basically a connection is merely attempted, but it does not report success
of said connection. The sentence of "pg_isready --help" is somehow
ambiguous:
"pg_isready issues a connection check to a PostgreSQL database.", but no
one specified whaa a "connection check" is. I can understand that you
would expect to be an actual connection:-)
ISTM that the doc should be clarified about what is a "connection check",
and that it is not working a connection.
If you want to check that your parameters are ok, probably you want to
issue an actual psql run, eg:
psql <my param> -c "SELECT 'ok'"
--
Fabien.
On Mon, Apr 13, 2020 at 04:17:21PM +0200, Fabien COELHO wrote: > Basically a connection is merely attempted, but it does not report success > of said connection. The sentence of "pg_isready --help" is somehow > ambiguous: > > "pg_isready issues a connection check to a PostgreSQL database.", but no one > specified whaa a "connection check" is. I can understand that you would > expect to be an actual connection:-) > > ISTM that the doc should be clarified about what is a "connection check", > and that it is not working a connection. Yeah, that matches my impression when reading this thread. Perhaps the docs had better emphasize that --timeout is a simple mapping for the connection parameter connect_timeout in this case? My point is that the logic tells us that the timeout is in effect when a connection has been started, but not completed yet. And the docs of pg_isready tell us that: "The maximum number of seconds to wait when attempting connection before returning that the server is not responding." So this does not really insist on the point that a timeout has no effect on a connection immediately failing because of an incorrect parameter set. -- Michael
