@@ -1467,19 +1467,19 @@ export abstract class Variable {
14671467 async palloc ( size : string ) {
14681468 await this . checkCanAlloc ( ) ;
14691469
1470- /* TODO: use MemoryContextAllocExtended with NULL returning */
14711470 if ( this . context . hasPalloc ) {
14721471 try {
1472+ /*
1473+ * Once there was an idea to use MemoryContextAllocExtended
1474+ * passing MCXT_NO_OOM, but actually, this is not very helpful:
1475+ * our allocations are too small (I am sure no allocations
1476+ * greater than 1kB bytes will be done) and more over, when
1477+ * using the former function we should be aware if we are in
1478+ * backend or frontend, so introducing this function usage here
1479+ * will just add more headaches than profit.
1480+ */
14731481 return ( await this . evaluate ( `palloc(${ size } )` ) ) . result ;
14741482 } catch ( err ) {
1475- /*
1476- * I will not allocate huge amounts of memory - only small *state* structures,
1477- * and expect, that there is always enough memory to allocate it.
1478- *
1479- * So, only invalid situation - this is old version of PostgreSQL,
1480- * so `palloc` implemented as macro and we need to invoke `MemoryContextAlloc`
1481- * directly.
1482- */
14831483 if ( ! isEvaluationError ( err ) ) {
14841484 throw err ;
14851485 }
@@ -1489,6 +1489,13 @@ export abstract class Variable {
14891489 }
14901490 }
14911491
1492+ /*
1493+ * We failed to invoke 'palloc' above. This can happen in the only
1494+ * situation - we are in old PG version (where palloc is a macro)
1495+ * executing backend logic (for our supported version 'palloc' on
1496+ * frontend is implemented as function). So we can assume that
1497+ * MemoryContextAlloc DOES exist.
1498+ */
14921499 const result = await this . evaluate ( `MemoryContextAlloc(CurrentMemoryContext, ${ size } )` ) ;
14931500 return result . result ;
14941501 }
0 commit comments