Research impact and feasibility of building the Postgres AMI with the same compiler flags provided by the Docker image

[Paul Cioanca]

Context

The official Postgres Docker image, off of which we base our Docker builds, is built using different compiler flags than the ones we're using to build Postgres in the AMI

Need to investigate the impact and feasibility of building Postgres with the same compiler flags that are delivered in the Docker build.

AMI build:
'--with-llvm' '--with-openssl' '--with-systemd' '--with-uuid=e2fs' '--with-libxml' '--with-icu' '--with-lz4'

Docker build:
'--with-tcl' '--with-perl' '--with-python' '--with-pam' '--with-openssl' '--with-systemd' '--with-libxml' '--with-libxslt' '--enable-nls' '--enable-thread-safety' '--enable-debug' '--enable-dtrace' '--disable-rpath' '--with-uuid=e2fs' '--with-gnu-ld' '--with-gssapi' '--with-ldap' '--with-icu' '--with-llvm' '--with-lz4' '--with-zstd'

[Div Arora]

fwiw we've wanted to move off the base postgres image and use a vanilla ubuntu image. Right now our final image includes two different builds, no?

[Paul Cioanca]

fwiw we've wanted to move off the base postgres image and use a vanilla ubuntu image.

That is a better idea than putting time into this, would bring us even closer to parity.

Right now our final image includes two different builds, no?

Yeah, we deliver the same extensions, but wrt to the base Postgres feature-set, they're different.
Encountered reports of users developing locally, and then encountering missing features when moving to their production projects created on the platform - namely ICU, which we delivered to prod today.

[Paul Cioanca]

Closing in favour of #513