Behaviour change between 9.5.20 and 9.5.21?

[vpzomtrrfrt]

When running docker run --rm postgres:9.5.20-alpine, the database successfully starts up, but with docker run --rm postgres:9.5.21-alpine, I get this output instead:

Error: Database is uninitialized and superuser password is not specified.
       You must specify POSTGRES_PASSWORD for the superuser. Use
       "-e POSTGRES_PASSWORD=password" to set it in "docker run".

       You may also use POSTGRES_HOST_AUTH_METHOD=trust to allow all connections
       without a password. This is *not* recommended. See PostgreSQL
       documentation about "trust":
       https://www.postgresql.org/docs/current/auth-trust.html

Is this an expected change?

[vpzomtrrfrt]

Based on 42ce743 it seems like it's intentional, but I find it odd to change something like that on a minor release

[aengelberg]

I just observed the same issue when bumping 9.6.16 => 9.6.17.

[vpzomtrrfrt]

See also #658, the PR that seems to have introduced this

[yosifkit]

We were convinced to make it more secure by default and were aware that this would break some users. Apologies for breaking changes. 🙇‍♂️ We felt that the increased security out-weighed the breakage. See #658 and #580.

If you know that you want to be insecure (i.e. any one can connect without a password from anywhere), then POSTGRES_HOST_AUTH_METHOD=trust is how you opt in to that.

We really recommend setting a password and it was really a bad decision by me in the beginning to continue to allow running the database without a password (#31 (comment) & #36)

[bxparks]

I wish a breaking change was not pushed out on a Friday. This broke our CI/CD pipeline, which I had to fix on a Saturday.

[CloudArchipelago]

Where in a CI/CD pipeline does one place those lines -e POSTGRES_PASSWORD=password or POSTGRES_HOST_AUTH_METHOD=trust ?

[chickahoona]

As always emotions fly high when a breaking change is introduced, causing work for others ;)

I appreciate the effort that you put into maintaining this image!

Maybe one can put the fix to add "POSTGRES_HOST_AUTH_METHOD=trust" somewhere more prominent. I get it that its part of the docker output when you start the image, yet sadly not if you start it with "-d". Then you are just wondering why the next docker command complains that the database is not up ;)

[bxparks]

@CloudArchipelago: It depends on what pipeline you are using. The two that I'm familiar with is GitHub and BitBucket:

• For GitHub, I think you put the POSTGRES_HOST_AUTH_METHOD=trust in the env section shown here: https://github.com/actions/example-services/blob/master/.github/workflows/postgres-service.yml
• We use BitBucket, and it goes in the environment section shown here: https://community.atlassian.com/t5/Bitbucket-questions/How-do-I-use-Postgres-in-Bitbucket-Pipelines/qaq-p/461910

(Of course, these articles and examples will need to be updated, since they no longer work as shown.)

I don't understand exactly how these pipelines actually configure and start the Postgres service in docker. So I don't know where the -e POSTGRES_PASSWORD=password would go.

And to be honest, I don't fully understand exactly what POSTGRES_HOST_AUTH_METHOD=trust does either since it's the first time I'm seeing it. I can probably figure it out in a few hours, but y'know, it's the long weekend. I got family to take care of, out of town guests visiting, housework to do, shopping to do, don't got time to spend on this...

[ManfredLange]

Was or is there consideration to switch to something like semantic versioning? If that was the case then this change, given it's intentional and a breaking changes, would cause a major revision change and everyone could deal with it accordingly. If such a change comes through not as a major, not even as a minor but merely as a patch release (z in x.y.z), then it is highly surprising and that is what trips up processes. Just putting it out there for consideration.

[kennethteh90]

Tried @bxparks proposed workaround for our CircleCI build (we use Github) and it worked. Simply add POSTGRES_HOST_AUTH_METHOD: trust.

- image: circleci/postgres:9.6-postgis-ram
       environment:
          POSTGRES_USER: 'username'
          POSTGRES_HOST_AUTH_METHOD: trust

[Nadock]

We were just burnt by this change and would give a big +1 to adopting semver to help mitigate this in the future.

However, I'm not posting just to pile on about semver, I have one other thing I'd like to point out. When our CI pipelines starting running with this newer container image (without POSTGRES_HOST_AUTH_METHOD or POSTGRES_PASSWORD) set the postgres container looked like it was coming up and staying up correctly. Because it wasn't clear the postgres container was the issue we spent a lot of time and effort looking in the wrong place.

In future, if a change is made where the database effectively doesn't work, the container should not just sit there happily doing nothing when it's actually broken. Had the postgres container been more noticeably broken we could have saved most of the time and effort we spent looking in the wrong place for the cause of the issue.

As a slight aside, is there an official we can monitor to know about future significant or breaking changes to this container in future?

[scaytrase]

Same here, broken our CI and local development