Closed sumanmichael closed 1 year ago
That server stopped
line is actually unrelated to the archiver -- just a couple more lines in your log you'll see PostgreSQL init process complete; ready for start up.
(and the server starting back up again, after which it does not shut down again). :sweat_smile:
(I used docker run --name postgres -it --rm --env POSTGRES_PASSWORD=foo postgres -c archive_mode=on -c archive_command=/bin/false -c log_min_messages=DEBUG5
and let it run for quite a while without issue beyond the expected constant complaints about the archive command failing before finally shutting it down myself :sweat_smile:)
Thank you @tianon for taking the time to test and provide feedback.
If the server stopped
line is unrelated to the archiver, I’m curious to know what is causing it. It is concerning because it results in the existing connections being dropped. I’ve observed that it typically occurs once, usually during the first or second set of failed archive commands.
To clarify, while the database does restart and recover, my main concern is the brief interruption in existing connections during this process.
I appreciate your assistance, and I want to mention that I am still able to reproduce this scenario. Please let me know if there’s any additional information or insights you can provide regarding this issue.
The server stopped
message is caused by the entrypoint and its initialization logic. It is the one printing PostgreSQL init process complete; ready for start up.
: https://github.com/docker-library/postgres/blob/cba2a05c03706daf5f9a66b93a447540b62df063/docker-entrypoint.sh#L332-L336
On first start (when the database hasn't yet been initialized), the entrypoint script goes through these steps (the _main
function):
$PGDATA
directory exists; fix permissions if possible)postgres
user (if container was started as root
)initdb
(postgres binary to initialize database files)$POSTGRES_HOST_AUTH_METHOD
(or default password_encryption
) to pg_hba.conf
$POSTGRES_DB
database/docker-entrypoint-initdb.d/
exec
(so that postgres
is pid 1 of the container) to run PostgreSQL server, but this time listening for remote connectionsOnly steps 1, 2 and 9 are done if the database files already exist.
Because the temporary server only listens internally and only happens on first initialization, it cannot affect any external connections. External connections to postgres
cannot happen until initialization is fully complete.
Side note: you will eventually need a volume for /var/lib/postgresql/data
so that you can control the lifecycle of your database files.
Thanks @yosifkit..! This helped me to debug my case further.
In my case, it's actually crashing due to pgbackrest archive-push ...
command being called as archive_command in async mode. I've changed to sync mode. It worked.
Closing the issue.
Issue Description
Current Behavior: When the archive command fails, the PostgreSQL database/container restarts intermittently. Note: This behavior is not observed in bare metal/non-Docker installations of PostgreSQL.
Expected Behavior: The PostgreSQL database/container should handle failures of the archive command gracefully, without causing intermittent restarts.
Steps to Reproduce
In
docker-compose.yml
, add flags topostgres
commandarchive_mode=on
,archive_command=/bin/false
(here, /bin/false is used to simulate any failing command) andlog_min_messages=DEBUG5
(for verbose logs)Now, Start the PostgreSQL container using Docker Compose.
Logs:
In logs, I see
archiver process shutting down
is followed by adatabase system is shut down
and thenserver stopped
(marked below lines with ---> )Complete Logs are available here: pgdb-docker.log
Additional Information: Docker Engine Version: 24.0.2 Docker Compose Version: v2.18.1