Re: BUG #15222: pg_isready fails connection after previous pg_isreadyclaims success - Mailing list pgsql-bugs
| From | Jon Watte |
|---|---|
| Subject | Re: BUG #15222: pg_isready fails connection after previous pg_isreadyclaims success |
| Date | |
| Msg-id | CAJgyHGOWmyjmiQWoUieV=naVkx2uC1q7ngMfrtoEqjT+Y1rZ=A@mail.gmail.com Whole thread Raw |
| In response to | Re: BUG #15222: pg_isready fails connection after previous pg_isready claims success (Tom Lane <tgl@sss.pgh.pa.us>) |
| List | pgsql-bugs |
I think I'm slightly closer to the culprit.
It appears that the Docker container re-starts Postgres the first time it's launched as part of initial set-up.
I guess that my "pg_ready" and "select 1" statements hit the window while the process is up, but re-configuring itself.
I think this is a surprising way of structuring the container -- why wouldn't this one-time setup just be run as part of baking the container image?
I could call "docker logs" and look for PostgreSQL init process complete; ready for start up. in my wait_for_postgres function, perhaps?
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
pg_ctl -D /var/lib/postgresql/data -l logfile start
WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
waiting for server to start....2018-05-31 22:25:00.211 UTC [76] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2018-05-31 22:25:00.227 UTC [77] LOG: database system was shut down at 2018-05-31 22:25:00 UTC
2018-05-31 22:25:00.232 UTC [76] LOG: database system is ready to accept connections
done
server started
ALTER ROLE
/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
waiting for server to shut down...2018-05-31 22:25:00.391 UTC [76] LOG: received fast shutdown request
.2018-05-31 22:25:00.395 UTC [76] LOG: aborting any active transactions
2018-05-31 22:25:00.398 UTC [76] LOG: worker process: logical replication launcher (PID 83) exited with exit code 1
2018-05-31 22:25:00.398 UTC [78] LOG: shutting down
2018-05-31 22:25:00.429 UTC [76] LOG: database system is shut down
done
server stopped
PostgreSQL init process complete; ready for start up.
2018-05-31 22:25:00.507 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2018-05-31 22:25:00.507 UTC [1] LOG: listening on IPv6 address "::", port 5432
2018-05-31 22:25:00.509 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2018-05-31 22:25:00.528 UTC [99] LOG: database system was shut down at 2018-05-31 22:25:00 UTC
2018-05-31 22:25:00.535 UTC [1] LOG: database system is ready to accept connections
Sincerely,
Jon Watte
--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson
On Thu, May 31, 2018 at 3:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jon Watte <jwatte@gmail.com> writes:
> How do I best turn on log_connections in the postgres log container?
Somebody else will have to answer that --- I'm not very familiar with
any of the available container packagings. If nothing else, ALTER
SYSTEM followed by a DB restart would do it, but there may be a nicer
way.
regards, tom lane
pgsql-bugs by date: