Latest version of postgres container is broken. The previous one which was released 10 ago is working fine. Is it possible to keep at least 2 latest 10.4 versions?

[alomov]

No description provided.

[wglambert]

Broken in what way

[alomov]

Container goes into restart cycle. The previous version is working fine.

[wglambert]

Could you also give the commands you ran and any relevant contextual files for reproducing the issue

[willglynn]

My images broke recently too.

fe89a60 changes docker-entrypoint.sh from set -e to set -Eeo pipefail, which is fine – except that docker-entrypoint.sh doesn't run user-provided scripts, it .s them. My scripts ran fine in the old shell environment but fail with the new one, which causes the container to exit.

[willglynn]

All right, I've got it.

My postgres-derived Docker images run a script to restore a PostgreSQL dump on startup. Images based on older postgres work fine, but images based on the newer postgres fail.

The dump I'm trying to restore is a tar-format backup created by pg_dump -Ft | gzip. Since it's a tarball, we can use tar to inspect it. Its contents looks like:

# tar tvzf snapshot.pgdump 
-rw------- postgres/postgres    565447 2018-05-30 11:51:43 toc.dat
-rw------- postgres/postgres         5 2018-05-30 11:51:43 4401.dat
-rw------- postgres/postgres         5 2018-05-30 11:51:43 4403.dat
-rw------- postgres/postgres         5 2018-05-30 11:51:43 4404.dat
-rw------- postgres/postgres         5 2018-05-30 11:51:43 4395.dat
-rw------- postgres/postgres         5 2018-05-30 11:51:43 4407.dat
…
-rw------- postgres/postgres         5 2018-05-30 11:51:43 4728.dat
-rw------- postgres/postgres    493857 2018-05-30 11:51:43 restore.sql

A script restores this into a postgres:10-alpine-derived image by calling gunzip < snapshot.pgdump | pg_restore -Ft. pg_restore successfully completes the restore and exits with code 0. This script is named /docker-entrypoint-initdb.d/restore.sh, and thus gets invoked automatically whenever this derived image is launched.

It turns out that pg_restore -Ft exits 0 before reading the entire archive – specifically, it never reads the restore.sql at the end. gunzip is thus unable to finish decompression and reports this condition by exiting with a status s where WIFSIGNALED(s) && WTERMSIG(s) == SIGPIPE.

This used to be fine since sh saw pg_restore's successful exit and considered the operation a success. (This is the desired behavior, since the restore was fully and successfully completed, even though it didn't read the entire input.) fe89a60 changed this script's environment to include set -o pipefail, making gunzip's SIGPIPE a fatal condition. New images containing this script thus successfully complete the restore, then exit with code 141 and tear down the container.

In summary:

1. pg_restore -Ft (10.4) doesn't fully consume output written by pg_dump -Ft (9.5.13)
2. fe89a60 sets -o pipefail on user-provided scripts

This combination broke my postgres-derived images. I'm mitigating downstream and don't need any action here, but I do find it surprising that my #!/bin/sh -e was not good enough to ensure a consistent shell execution environment.

[tianon]

Ouch, that was definitely not intentional -- I'll get a PR up shortly to fix that here too. Sorry about that!