On Tue, Jun 30, 2026 at 2:31 AM Thom Brown <[email protected]> wrote: > On Mon, 29 Jun 2026 at 14:09, Thomas Munro <[email protected]> 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? */
