Re: Small memory fixes for pg_createsubcriber

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: 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 16:02:04
Message-ID: 3337507.1739376124@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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 ...

This seems like the sort of bug that Coverity could detect if only it
knew to look, but I have no idea if it could be configured that way.
Maybe some weird lashup with a debugging malloc library would be
another way.

regards, tom lane

[1] https://www.postgresql.org/message-id/20240709225934.746y5fg3kgxkyant@awork3.anarazel.de

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2025-02-12 16:46:38 Re: Small memory fixes for pg_createsubcriber
Previous Message Alvaro Herrera 2025-02-12 16:00:19 Re: [PATCH] Optionally record Plan IDs to track plan changes for a query