From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Euler Taveira <euler(at)eulerto(dot)com>, "ranier(dot)vf(at)gmail(dot)com" <ranier(dot)vf(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Small memory fixes for pg_createsubcriber |
Date: | 2025-02-12 18:35:20 |
Message-ID: | 3364495.1739385320@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
use-dmalloc-within-libpq-hack-hack-hack.patch | text/x-diff | 2.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Herrera | 2025-02-12 18:39:39 | Re: pg_stat_statements and "IN" conditions |
Previous Message | Robert Haas | 2025-02-12 18:19:11 | Re: explain analyze rows=%.0f |