Add "build from github.com/postgres/postgres" variation #1242

Activity

1. tianon commented on May 28, 2024

   

   tianon

   on May 28, 2024

   Member

   More actions

   A parallel/similar request to this one is docker-library/golang#464 (which has some useful discussion on it including some constraints this would have to follow such as not auto-updating "too often")

   I'd also like to avoid creating our own name for this thing, especially if there's already a common term in use in the PostgreSQL community for describing this (for example, in Go, it's common to refer to "Go tip" as the latest development version, to the point of having a whole website deployed on https://tip.golang.org/ for the in-development version).
2. tianon commented on May 28, 2024

   

   tianon

   on May 28, 2024

   Member

   More actions

   To my second point, it appears "devel" is probably the right term: https://www.postgresql.org/docs/devel/index.html

   👍React with 👍1Reacted by Nikolas Schröter
3. vlsi commented on May 29, 2026

   

   vlsi

   on May 29, 2026

   Author

   More actions

   The "from source" build keeps coming up, so here's a concrete proposal to move it forward.

   Idea: add a source-built variant, tagged devel (matching postgresql.org/docs/devel/), built from github.com/postgres/postgres. The one reproducibility concern with a moving branch is easy to handle the same way the released images already pin versions: store the resolved commit in versions.json and have update.sh bump it on a schedule (say weekly). A given postgres:devel image then maps to one specific commit and rebuilds reproducibly from it; only the refresh cadence is new.

   Rough shape (multi-stage to keep the toolchain out of the final image; the user/dir/entrypoint boilerplate is identical to the existing variants and omitted here):

   FROM debian:trixie-slim AS build
   RUN apt-get update && apt-get install -y --no-install-recommends \
         build-essential git ca-certificates bison flex \
         libicu-dev llvm-dev clang \
         libreadline-dev zlib1g-dev liblz4-dev libzstd-dev libssl-dev \
         libxml2-dev libxslt1-dev libperl-dev python3-dev tcl-dev \
         uuid-dev libldap2-dev libpam0g-dev \
     && rm -rf /var/lib/apt/lists/*
   
   # Resolved by update.sh and pinned in versions.json, so :devel is reproducible.
   ARG PG_SHA
   RUN git clone https://github.com/postgres/postgres.git /usr/src/postgresql \
     && git -C /usr/src/postgresql checkout "$PG_SHA"
   
   WORKDIR /usr/src/postgresql
   RUN ./configure \
         --with-icu --with-llvm --with-lz4 --with-zstd \
         --with-openssl --with-libxml --with-libxslt \
         --with-perl --with-python --with-tcl \
         --with-ldap --with-pam --with-uuid=e2fs \
     && make -j "$(nproc)" world-bin \
     && make install-world-bin
   
   FROM debian:trixie-slim
   COPY --from=build /usr/local/pgsql /usr/local/pgsql
   # install the runtime libraries, gosu and locales, then the shared user setup
   COPY docker-entrypoint.sh docker-ensure-initdb.sh /usr/local/bin/
   ENV PATH=/usr/local/pgsql/bin:$PATH PGDATA=/var/lib/postgresql/data
   ENTRYPOINT ["docker-entrypoint.sh"]
   EXPOSE 5432
   STOPSIGNAL SIGINT
   CMD ["postgres"]

   In the repo this would slot in as a Dockerfile-source.template plus a devel entry in versions.json/versions.sh, reusing your existing docker-entrypoint.sh.

   Open questions for you:

   • Is the "pin the commit in versions.json, refresh weekly" model acceptable for reproducibility?
   • One source variant, or both Debian- and Alpine-based?
   • Where should the version string come from for SELECT version() — NNdevel plus the short SHA?

   I have a working source-built HEAD image along these lines (multi-stage, ~390 MB, drop-in with your docker-entrypoint.sh), which I use to test pgJDBC against unreleased PostgreSQL: https://github.com/vlsi/pgjdbc/pull/7/changes#diff-06d3c2b6b5ee29fd9a26da9c13d981861969ce0d957b0db8c4be10db577ed8e4. Happy to turn this into a proper PR against the templates if the approach sounds right.
4. tianon commented on Jun 2, 2026

   

   tianon

   on Jun 2, 2026

   Member

   More actions

   We build Alpine from source because we have to (upstream doesn't publish official Alpine builds), not because we want to -- I wouldn't feel comfortable maintaining builds that are ostensibly the "same" as our standard default Debian builds if we're building them from source (and I've several times considered deprecating and removing our Alpine builds on these very grounds, combined with the fact that Alpine isn't officially supported by upstream in any way I can find).

   If upstream provided builds of such a thing, that would be interesting, but they'd have to be pinned to at most a weekly cadence, and they'd have to be available for a "reasonable" amount of time (ie, builds still available for rebuilds to succeed for some period of time after the build is published/consumed).
5. vlsi commented on Jun 3, 2026

   

   vlsi

   on Jun 3, 2026

   Author

   More actions

   A concrete pointer on the "upstream-provided builds" angle: apt.postgresql.org already ships a *-pgdg-snapshot suite for every supported Debian and Ubuntu release (dists index). The PostgreSQL server is tracked from upstream git, so the next major version shows up there before its release (wiki FAQ). Both amd64 and arm64 are published, and the current PG 19 devel packages also sit in the regular pgdg suite.

   Example sources.list:

   deb http://apt.postgresql.org/pub/repos/apt/ trixie-pgdg-snapshot main 19
   

   For freshness, today's trixie-pgdg-snapshot carries postgresql-19 at 19~beta1-1~20260603.0215.gffeda04259b.pgdg13+1 — snapshot timestamp 02:15 UTC, suite Release refreshed at 07:26 UTC. The cadence runs well below daily in practice.

   The structural piece that isn't in shape is how snapshots are addressed, not just how long they're retained. The suite's Packages file carries only the current snapshot; superseded ones leave the suite and aren't reachable through apt. So pinning a specific snapshot in versions.json (the way pgdg-stable versions are pinned today) has no obvious mechanism. There's no dated suite, and apt can't resolve to a .deb that no longer appears in the index, even if it lingers in pool/. Retention alone doesn't help, since there's nothing for the rebuild to address.

   The model that would naturally support this is the one snapshots.debian.org uses for the main Debian archive: dated, immutable suites that a rebuild can resolve against deterministically. If pgdg-snapshot exposed something equivalent (dated suites, or per-snapshot tags resolvable by apt), Official Images could pin and rebuild against specific snapshots in their usual model, with whatever retention the maintainers were comfortable with. Without that, this path doesn't work for a postgres:devel image, regardless of cadence.

   Does that shape match what you'd need from the upstream side?
6. tianon commented on Jun 5, 2026

   

   tianon

   on Jun 5, 2026

   Member

   More actions

   Yeah, we would need something exactly like that (or at the very least, something more generous than just a single snapshot in that APT repo and good instructions for appropriate version pinning via apt_preferences so we can lock all the appropriate packages accurately).