On Tue, 30 Jun 2026 at 00:24, Thomas Munro <[email protected]> wrote: > > 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? */
I see, yeah, that does seem wrong. So would it just be a matter of moving ecpg_clear_auto_mem() out of ecpg_do_prologue() and put it into ecpg_do_epilogue() so that it cleans up at the end of the statement instead of the start of the next one? Thom
