Re: Issue with server side statement-level rollback

Hi,

On 2020-11-12 11:40:22 +0100, Gilles Darold wrote:
> The problem we are encountering is when PostgreSQL is compiled in debug
> mode with --enable-cassert. At line 1327 of src/backend/tcop/pquery.c
> the following assert fail:
> 
>     /*
>      * Clear subsidiary contexts to recover temporary memory.
>      */
>     Assert(portal->portalContext == CurrentMemoryContext);
> 
>     MemoryContextDeleteChildren(portal->portalContext);
> 
> This extension, although it is a risky implementation, works extremely
> well when used in a fully controlled environment. It avoid the latency
> of the extra communication for the RELEASE+SAVEPOINT usually controlled at
> client side. The client is only responsible to issue the "ROLLBACK TO
> autosavepoint"
> when needed.  The extension allow a high performances gain for this feature
> that helps customers using Oracle or DB2 to migrate to PostgreSQL.
> 
> 
> Actually with the extension the memory context is not CurrentMemoryContext
> as expected by the assert.

What is it instead? I don't think you really can safely be in a
different context at this point. There's risks of CurrentMemoryContext
pointing to a deleted context, and risks of memory leaks, depending on
the situation.


> As there is no hook or API that could allow a perfect server side
> integration of this feature we have done what is possible to do in the
> extension.

> So my question is should we allow such use through an extension and in
> this case what is the change to PostgreSQL code that could avoid the
> assert crash? Or perhaps we have missed something in this extension to
> be able to make the assert happy but I don't think so.

Without more detail of what you actually are precisely doing, and what
the hooks / integration you'd like would look like, it's hard to comment
usefully here.

Greetings,

Andres Freund