Hi, On Sat, May 24, 2025 at 10:10 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > The DirectModify code path relies on PG_TRY blocks to ensure that it > releases the PGresult for the foreign modify command, but that can't > work because (at least in cases with RETURNING data) the PGresult has > to survive across successive calls to postgresIterateDirectModify. > If an error occurs in the query in between those steps, we have no > opportunity to clean up.
Ugh. > I thought of fixing this by using a memory context reset callback > to ensure that the PGresult is cleaned up when the executor's context > goes away, and that seems to work nicely (see 0001 attached). > However, I feel like this is just a POC, because now that we have that > concept we might be able to use it elsewhere in postgres_fdw to > eliminate most or even all of its reliance on PG_TRY. That should be > faster as well as much less bug-prone. But I'm putting it up at this > stage for comments, in case anyone thinks this is not the direction to > head in. I think that that is a good idea; +1 for removing the reliance not only in DirectModify but in other places. I think that that would be also useful if extending batch INSERT to cases with RETURNING data in postgres_fdw. Thanks for working on this! Best regards, Etsuro Fujita
