Holger Krug ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Misleading documentation of `palloc'
Long Description
In section 12.5.6 "Writing Code" of the "PostgreSQL 7.2 Programmer's
Guide" the following is said:
"When allocating memory, use the PostgreSQL routines `palloc' and
`pfree' instead of the corresponding C library routines `malloc' and
`free'. The memory allocated by `palloc' will be freed automatically
at the end of each transaction, preventing memory leaks."
This is not actually wrong but *misleading*, because memory allocated by `palloc' in a
user-defined server-side C language function is freed not only at transaction end but
actually at the end of each TransactionCommand - or even more: at the end of each
expression evaluation. The reason is, that the `CurrentMemoryContext' used for the
evaluation of such functions is `PlanExprContext', which is a
child of `TransactionCommandContext', which is a child of
`TopTransactionContext'.
As a consequence is appears that, given the following situation:
- a user-defined function `get_pointer()' which allocates server
memory (with `palloc') and returns a pointer to it
- a user-defined function `get_data(pointer)' which gets the pointer
as an argument and returns the data saved at the allocated memory
it is possible to use `get_pointer()' and `get_data(pointer)' together
if used within one expression, but it is impossible to use them in two
different expressions:
- `get_data(get_pointer())' will work
- the following PLpgSQL command sequence won't work:
DECLARE
p pointer;
BEGIN
p := get_pointer();
RETURN get_data(p);
END;
I propose to make the documentation more concise in this point and to add a macro like:
#define palloc_tx(sz) MemoryContextAlloc(TopTransactionContext, (sz))
for the convenience of the server-side programmer to be used for memory allocation in
server-side functions, in cases when the allocated memory shall be valid up to the end
of the current transaction.
Sample Code
No file was uploaded with this report
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
