Remove double check when field_name is not NULL in be-secure-openssl.c
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:t44818psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 07:49 AM.
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 t44818_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 t44818_1 && git checkout t44818_1Patchset v1 (message #1) is on t44818_1
Hi
Attached a small fix to remove double check when field_name is not NULL in be-secure-openssl.c.
The double check is introduced in 13cfa02f7 for "Improve error handling in backend OpenSSL implementation".
Regards,
Tang
On 15 Sep 2021, at 10:06, tanghy.fnst@fujitsu.com wrote:
Attached a small fix to remove double check when field_name is not NULL in be-secure-openssl.c.
The double check is introduced in 13cfa02f7 for "Improve error handling in backend OpenSSL implementation".
The proposal removes a second == NULL check on field_name in the case where
OBJ_nid2sn() returns an ASN1_OBJECT. This is not in a hot path, and the ASM
generated is equal under optimization levels so I don't see the value in the
code churn and the potential for collisions during backpatching around here.
--
Daniel Gustafsson https://vmware.com/
On Wednesday, September 15, 2021 6:54 PM, Daniel Gustafsson <daniel@yesql.se> wrote:
The proposal removes a second == NULL check on field_name in the case where
OBJ_nid2sn() returns an ASN1_OBJECT. This is not in a hot path, and the ASM
generated is equal under optimization levels so I don't see the value in the
code churn and the potential for collisions during backpatching around here.
Thanks for your kindly explanation.
Got it.
Regards,
Tang