On Wed, Oct 12, 2022 at 11:08:25PM -0400, Tom Lane wrote:
> Julien Rouhaud <rjuju123@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.
