On Wed, Oct 12, 2022 at 11:08:25PM -0400, Tom Lane wrote: > Julien Rouhaud <rjuju...@gmail.com> writes: > > We can change the API to accept an optional new value (and the few other > > needed > > information) when cleaning the old one, but that's adding some complication > > just to deal with a possible error in pfree. So it still unclear to me > > what to > > do here. > > I think it's worth investing some effort in ensuring consistency > of persistent data structures in the face of errors. I doubt it's > worth investing effort in avoiding leaks in the face of errors.
So if e.g. LET myvar = somebigstring; errors out because of hypothetical pfree() error, it would be ok to leak that memory as long as everything is consistent, meaning here that myvar is in a normal "reset" state? > In any case, thinking of it in terms of "trapping" errors is the > wrong approach. We don't have a cheap or complication-free way > to do that, mainly because you can't trap just one error cause. > > It may be worth looking at the GUC code, which has been dealing > with the same sorts of issues pretty successfully for many years. The GUC code relies on malloc/free, so any hypothetical error during free should abort and force an emergency shutdown. I don't think it's ok for session variables to bypass memory contexts, and forcing a panic wouldn't be possible without some PG_TRY block.
