Sibtay Abbas <[EMAIL PROTECTED]> writes:
> in pl_comp.c, plpgsql_build_variable takes a pointer to a PLpgSQL_type
> structure, which is always a malloc'ed instance(since we always use
> plpgsql_build_datatype function).
As of current sources it's palloc'd, and should be released if the
function is
This dicussion reminds me of a possible memory leak in plpgsql's code. In case you are interested in it;
in pl_comp.c, plpgsql_build_variable takes a pointer to a PLpgSQL_type
structure, which is always a malloc'ed instance(since we always use
plpgsql_build_datatype function). The switch stateme
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> wrote
>> No, because you're thinking in terms of the backend environment, and
>> generally in the backend the answer to "when to use malloc directly"
>> is "never".
> Well, except before MemoryContext mechanism is set up?
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> No, because you're thinking in terms of the backend environment, and
> generally in the backend the answer to "when to use malloc directly"
> is "never".
>
Well, except before MemoryContext mechanism is set up? For example, the
functions(e.g., GUC, vfd) u
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> There are several places in both backend and tools that forget to check the
> return value of malloc(). For example(8.0.1),
> backend/port/dynloader/beos.c/pg_dlopen()
Dead port, probably not worth fixing.
> backend/bootstrap/bootstr
There are several places in both backend and tools that forget to check the
return value of malloc(). For example(8.0.1),
backend/port/dynloader/beos.c/pg_dlopen()
backend/bootstrap/bootstrap.c/AddStr()
port/strdup.c/strdup()
bin/pg_dump/common.c/findParentsByOid()
...
I am t
