Robert Haas <robertmhaas@xxxxxxxxx> writes: > On Mon, Aug 27, 2012 at 9:58 AM, Bruce Momjian <bruce@xxxxxxxxxx> wrote: >> From Tom Lane in the above thread: >>> Hmm. I can see how that would happen if you're using one of the Windows >>> environments wherein malloc's done inside libpq have to be free'd inside >>> libpq. (The PQExpBuffer support code is in libpq...) >> Late reply, but I don't see any way we could fix this easily. > To me it seems like mostly a case of chasing down all the places where > this happens. It's not impossible to do; it's just a bunch of work > that nobody's gotten excited about doing yet. We've fixed similar > issues in many other cases, IIUC. Well, the problem with what I suspect you're thinking of is that even after we fixed all the existing trouble spots, it would keep on breaking. Unless we found some mechanical way to warn about unsafe coding; which in itself would be more work than I want to put into this. However, a plan B occurs to me: what about preventing pg_dump from using libpq's copy of PQExpBuffer? IIUC, a copy of the PQExpBuffer code statically linked into pg_dump would be free of this problem. There's not so much code there that this would be an intolerable price to pay. (Besides, we could probably arrange for the extra copy to happen only on Windows.) regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
