Horton

Re: Small memory fixes for pg_createsubcriber

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, Euler Taveira <euler@eulerto.com>, "ranier.vf@gmail.com" <ranier.vf@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-02-12T18:35:20Z
Lists: pgsql-hackers

Attachments

I experimented with the other approach: hack libpq.so to depend on
dmalloc, leaving the rest of the system alone, so that libpq's
allocations could not be freed elsewhere nor vice versa.

It could not even get through initdb, crashing here:

replace_guc_value(char **lines, const char *guc_name, const char *guc_value,
                  bool mark_as_comment)
{
    PQExpBuffer newline = createPQExpBuffer();

    ...
    free(newline);            /* but don't free newline->data */

which upon investigation is expected, because createPQExpBuffer is
exported by libpq and therefore is returning space allocated within
the shlib.  Diking out that particular free() call just allows it
to crash a bit later on, because initdb is totally full of direct
manipulations of PQExpBuffer contents.

This indicates to me that we have a *far* larger problem than
we thought, if we'd like to be totally clean on this point.

Realistically, it's not going to happen that way; it's just
not worth the trouble and notational mess.  I think if we're
honest we should just document that such-and-such combinations
of libpq and our client programs will work on Windows.

For amusement's sake, totally dirty hack-and-slash patch attached.
(I tested this on macOS, with dmalloc from MacPorts; adjust SHLIB_LINK
to suit on other platforms.)

			regards, tom lane

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.