TLS checking in pgstat
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t42603psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 26, 2026 at 04:43 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t42603_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t42603_1 && git checkout t42603_1Patchset v1 (message #1) is on t42603_1
As I mentioned in [1]FAB21FC8-0F62-434F-AA78-6BD9336D630A@yesql.se, checking (struct Port)->ssl for NULL to determine
whether TLS is used for connection is a bit of a leaky abstraction, as that's
an OpenSSL specific struct member. This sets the requirement that all TLS
implementations use a pointer named SSL, and that the pointer is set to NULL in
case of a failed connection, which may or may not fit.
Is there a reason to not use (struct Port)->ssl_in_use flag which tracks just
what we're looking for here? This also maps against other parts of the
abstraction in be-secure.c which do just that. The attached implements this.
cheers ./daniel
[1]: FAB21FC8-0F62-434F-AA78-6BD9336D630A@yesql.se
On Sun, Jun 28, 2020 at 1:39 PM Daniel Gustafsson <daniel@yesql.se> wrote:
As I mentioned in [1], checking (struct Port)->ssl for NULL to determine
whether TLS is used for connection is a bit of a leaky abstraction, as
that's
an OpenSSL specific struct member. This sets the requirement that all TLS
implementations use a pointer named SSL, and that the pointer is set to
NULL in
case of a failed connection, which may or may not fit.Is there a reason to not use (struct Port)->ssl_in_use flag which tracks
just
what we're looking for here? This also maps against other parts of the
abstraction in be-secure.c which do just that. The attached implements
this.
Yeah, this seems perfectly reasonable.
I would argue this is a bug, but given how internal it is I don't think it
has any user visible effects yet (since we don't have more than one
provider), and thus isn't worthy of a backpatch.
Pushed.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>