From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: how to correctly react on exception in pfree function? |
Date: | 2022-10-13 03:08:25 |
Message-ID: | 887967.1665630505@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Julien Rouhaud <rjuju123(at)gmail(dot)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.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2022-10-13 03:26:02 | Re: how to correctly react on exception in pfree function? |
Previous Message | Julien Rouhaud | 2022-10-13 03:02:26 | Re: how to correctly react on exception in pfree function? |