Re: Per-thread leak in ECPG's memory.c

On Tue, Jun 30, 2026 at 2:31 AM Thom Brown <thom(at)linux(dot)com> wrote:
> On Mon, 29 Jun 2026 at 14:09, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > Hmm, I wonder why ecpg_raise() frees auto-allocated values for all
> > connections just because one connection raised an error.

> Digging into bug reports from that time, we get:
> https://www.postgresql.org/message-id/200611071423.kA7ENpJ1080586%40wwwmaster.postgresql.org
>
> "When using more than one database connection with ECPG, you might have
> obtained and freed blocks of data on one connection before trying to open
> the other.
> If the second connection fails, ECPGraise will be called and call
> ECPGfree_auto_mem. This can cause an invalid free() of a pointer you've
> already freed."

Thanks for finding that. Hmm, OK, but I was wondering about the
opposite scenario, where you *haven't* freed blocks of data before
doing something on another connection that frees everything for the
thread:

EXEC SQL AT con1 SELECT datname INTO :anything FROM pg_database;
EXEC SQL AT con2 ... something that reaches ecpg_raise() ...

/* Why should "anything" not be accessible, and mine to free(), here? */