Horton

Re: Small memory fixes for pg_createsubcriber

Ranier Vilela <ranier.vf@gmail.com>

View thread View on postgr.es
From: Ranier Vilela <ranier.vf@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Euler Taveira <euler@eulerto.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-02-12T16:46:38Z
Lists: pgsql-hackers

Attachments

Hi.

Em qua., 12 de fev. de 2025 às 13:02, Tom Lane <tgl@sss.pgh.pa.us> escreveu:

> Andres Freund <andres@anarazel.de> writes:
> > On 2025-02-11 13:32:32 -0300, Euler Taveira wrote:
> >> There is no bug. They are the same behind the scenes.
>
> > That *is* a bug. On windows the allocator that a shared library (i.e.
> libpq)
> > uses, may *not* be the same as the one that an executable
> > (i.e. pg_createsubscriber).  It's not correct to free memory allocated
> in a
> > shared library just with free, it has to go through the library's free.
>
> Indeed.  This is particularly pernicious because it will work even on
> Windows under common scenarios (which no doubt explains the lack of
> field reports).  From the last time we discussed this [1]:
>
>     It seems to work fine as long as a debug-readline is paired with a
>     debug-psql or a release-readline is paired with a release-psql.
>
> I wish we had some way to detect misuses automatically ...
>
Unfortunately, for now, there is only manual search.

In fact, after your post, I did a new search and found two other
occurrences.
(src/bin/pg_amcheck/pg_amcheck.c)

One fixed in the patch attached.
Another *dat->amcheck_schema* is it not worth the effort,
since the memory is not released at any point?

Trivial patch attached.

best regards,
Ranier Vilela

Commits

  1. pg_upgrade: Fix inconsistency in memory freeing

  2. pg_amcheck: Fix inconsistency in memory freeing

  3. Fix some inconsistencies with memory freeing in pg_createsubscriber

  4. Drop pre-existing subscriptions from the converted subscriber.