Re: ERROR: Memory exhausted in AllocSetAlloc(909324558) - Mailing list pgsql-hackers

From darcy@druid.net (D'Arcy J.M. Cain)
Subject Re: ERROR: Memory exhausted in AllocSetAlloc(909324558)
Date
Msg-id 20010609111235.E02A01A8B@druid.net
Whole thread Raw
In response to Re: ERROR: Memory exhausted in AllocSetAlloc(909324558)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ERROR: Memory exhausted in AllocSetAlloc(909324558)
List pgsql-hackers
Thus spake Tom Lane
> darcy@druid.net (D'Arcy J.M. Cain) writes:
> >> heap_formtuple is for constructing a tuple from scratch.  It sounds like
> >> you should be using heap_modifytuple instead.
> 
> > But I am using SPI_modifytuple().  The rest came from tracing that
> > function.
> 
> Hm.  Looks like the author of SPI_modifytuple didn't realize he could
> use heap_modifytuple :-(.  But he is correctly extracting the old data.
> I don't see anything wrong there, assuming that you are passing a
> relation descriptor that matches the original tuple.

Well, let's see.
   SPI_modifytuple (rel,rettuple,1,&targ_att,&newval,NULL)

Here are (I think) the relevant lines that get me the data for that call.

Datum
mk_cardnum(PG_FUNCTION_ARGS)
{   TriggerData *trigdata = (TriggerData *) fcinfo->context;   int         nargs;          /* # of arguments */   Datum
     newval;         /* new value of column */   char        **args;         /* arguments */   char        *relname;
  /* triggered relation name */   Relation    rel;            /* triggered relation */   HeapTuple   rettuple = NULL;
int        targ_att;   bool        isnull;   char        cardnum[48];
 
...   /* assume full error checking - leaving out for clarity */   rel = trigdata->tg_relation;   relname =
SPI_getrelname(rel);  targ_att = SPI_fnumber (tupdesc, args[0]);   newval = CStringGetDatum(cardnum);
 

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Next
From: Peter Eisentraut
Date:
Subject: Re: grant and SQL92