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
