Hi,
On 2025-02-12 19:08:31 -0500, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
> > I have looked at bit at the uses of PQescapeLiteral() and
> > PQescapeIdentifier() in the tree. On top of the one in pg_amcheck you
> > are just pointing to, there is an inconsistency in pg_upgrade.c for
> > set_locale_and_encoding() where datlocale_literal may be allocated
> > with a pg_strdup() or a PQescapeLiteral() depending on the path. The
> > code has been using PQfreemem() for the pg_strdup() allocation, which
> > is logically incorrect.
>
> Yeah, I suspected there would be places like that. It just hasn't
> mattered in practice up to now. (I have a vague recollection that
> Windows used to be pickier about this, but evidently not in recent
> years.)
It's a question of compiler / link options. If you e.g. have a debug psql
runtime linked against a non-debug libpq, the allocators for both will
differ. Or if you link an application statically while a library is built for
a shared C runtime. Or a few other such things.
But when building in the BF / CI we'll not typically encounter this issue
between libraries and binaries in our source tree, because they'll all be
built the same.
However, we have more recently hit this with external libraries we link
to. While it's not recommended, we commonly build (in BF/CI) a debug postgres
against production openssl, zstd etc. Which means they don't share
allocators, file descriptors etc.
Greetings,
Andres Freund
