Re: Initializing Datums for use with SPI_execute_plan - Mailing list pgsql-general

From Jack Orenstein
Subject Re: Initializing Datums for use with SPI_execute_plan
Date
Msg-id 7ecd811f0609191300h41d0c21ajca43f64510b79e35@mail.gmail.com
Whole thread Raw
In response to Re: Initializing Datums for use with SPI_execute_plan  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Initializing Datums for use with SPI_execute_plan
Re: Initializing Datums for use with SPI_execute_plan
List pgsql-general
On 9/19/06, Martijn van Oosterhout <kleptog@svana.org> wrote:
> On Tue, Sep 19, 2006 at 01:27:56PM -0400, Jack Orenstein wrote:
> > On 9/18/06, Jack Orenstein <jack.orenstein@gmail.com> wrote:
> > >---------- Forwarded message ----------
> > >From: Andrew - Supernews <andrew@supernews.net>
> > ...
> > > Jack> I have an int8 that I need as a Datum for use with
> > > Jack> SPI_execute_plan.
> > >
> > >Int64GetDatum(your_variable)
> >
> > which then has to be pfree'd, correct?
>
> Possibly, it probably depends on the architechture. The memory is being
> allocated in a per-call context IIRC so it'll be freed at the end of
> the function anyway. I wouldn't worry about it.

Can you provide some guidance (or point to some documentation) on how
to manage memory? Is the idea that I should (must?) not pfree
palloc'ed memory from Int64GetDatum, but I should free anything I
allocate myself using palloc? Or not even that?

The C extension I'm writing, which uses the SPI, will be called
thousands or millions of times as part of a data conversion -- I do
have to worry about memory leaks. Once the conversion completes, I
won't use the function any longer. But I'd rather not leak memory and
have to do something drastic to reclaim it, such as bouncing
postgresql.

Jack

pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Initializing Datums for use with SPI_execute_plan
Next
From: Ron Johnson
Date:
Subject: Re: Load a csv file into a pgsql table