From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Andres Freund <andres@anarazel.de>, Euler Taveira <euler@eulerto.com>,
        "ranier.vf@gmail.com" <ranier.vf@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Small memory fixes for pg_createsubcriber
In-reply-to: <Z601RQxTmIUohdkV@paquier.xyz>
References: <CAEudQAp=AW5dJXrGLbC_aZg_9nOo=42W7uLDRONFQE-gcgnkgQ@mail.gmail.com> <68d6d810-4ef1-4f62-b47f-89b21501249b@app.fastmail.com> <obqvpv4yx57lbnfiqvy4pmnfi2l5wn6xzoq2ftytxa426pa226@2sc46frt5xtb> <3337507.1739376124@sss.pgh.pa.us> <xseczrku4nm3p4rujapxiiuttpqrpagkbwrr2nlbnmwemh525y@3he54emhpqha> <Z601RQxTmIUohdkV@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Thu, 13 Feb 2025 08:56:53 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3490962.1739405311.1@sss.pgh.pa.us>
Date: Wed, 12 Feb 2025 19:08:31 -0500
Message-ID: <3490963.1739405311@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3490963.1739405311%40sss.pgh.pa.us>
Precedence: bulk

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.)

I spent a little time earlier today seeing what I could do with the
use-dmalloc patch I posted earlier.  It turns out you can get through
initdb after s/free/PQfreemem/ in just two places, and then the
backend works fine.  But psql is a frickin' disaster --- there's
free's of strings made with PQExpBuffer all over its backslash-command
handling, and no easy way to clean it up.  Maybe other clients will
be less of a mess, but I'm not betting on that.

			regards, tom lane