Hi,
On 2019-01-28 17:31:15 -0800, Andres Freund wrote:
> On 2019-01-29 04:17:33 +0300, Alexander Korotkov wrote:
> > I'm probably not yet understanding all the risks this code have. So far I see:
>
> I find these *more* than sufficient to not go to the PG_TRY/CATCH
> approach.
>
>
> > 1) One of functions called here performs database modification, while
> > it wasn't suppose to. So, it becomes not safe to skip subtransaction.
>
> It's not just data modifications. Even just modifying some memory
> structures that'd normally be invalidated by an xact abort's
> invalidation processing isn't safe.
>
>
> > 2) ERRCODE_DATA_EXCEPTION was thrown for unexpected reason. So, it
> > might appear that ERRCODE_DATA_EXCEPTION is not safe to ignore.
>
> It'd e.g. not surprise me very much if some OOM would end up translating
> to ERRCODE_DATA_EXCEPTION, because some library function returned an
> error due to ENOMEM.
>
>
> > Could you complete this list?
>
> 3) The expression changed the current expression context, GUCs or any
> other such global variable. Without a proper subtrans reset this
> state isn't reverted.
> 4) The function acquires an LWLOCK, buffer reference, anything resowner
> owned. Skipping subtrans reset, that's not released in that
> moment. That's going to lead to potential hard deadlocks.
> 99) sigsetjmp is actually pretty expensive.
And even if you, to address Tom's point about plpgsql, had a category
that could only be thrown by core code, and addressed 3) and 4) by
carefully and continuously auditing code, you'd still have the issue of
5) you'd likely leak memory at potentially prodiguous rate...
Greetings,
Andres Freund
