ERROR: Memory exhausted in AllocSetAlloc(909324558)
I saw someone else also saw this error. I am seeing it in 7.1.2 and I
think I may have tracked it down. It's after a different operation but
perhaps it is related.
I have written a trigger. It dies with that error when I make the
following call.
SPI_modifytuple (rel,rettuple,1,&targ_att,&newval,NULL)
I created targ_att as follows.
targ_att = SPI_fnumber (tupdesc, args[0]
This returns 23 in my case which is the correct field that I want to
modify. The existing value for that field is NULL. I looked at the
length of that fields with rel->rd_att->attrs[23]->attlen and it is -1.
I assume that that is OK for a NULL value.
I eventually followed this call to heaptuple.c. In heap_formtuple()
there is a call to ComputeDataSize() with the existing tuple, the value
I am changing to and the nulls. In that function the length (-1) is
added to the total length. This causes the problem I am seeing.
Am I misunderstanding the call? I thought that the nulls parameter was
to map out which values you were changing to were NULL. It appears
to be the value of the existing value. Why would I care about that value?
Is it up to me to find all the NULLS in an existing tuple before calling SPI
functions?
I called this function that way in an earlier version with no problem.
--
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.
darcy@druid.net (D'Arcy J.M. Cain) writes:
Am I misunderstanding the call? I thought that the nulls parameter was
to map out which values you were changing to were NULL.
heap_formtuple is for constructing a tuple from scratch. It sounds like
you should be using heap_modifytuple instead.
regards, tom lane
Thus spake Tom Lane
darcy@druid.net (D'Arcy J.M. Cain) writes:
Am I misunderstanding the call? I thought that the nulls parameter was
to map out which values you were changing to were NULL.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.
--
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.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.
regards, tom lane
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.darcy@druid.net (D'Arcy J.M. Cain) writes:
char cardnum[48];
...
newval = CStringGetDatum(cardnum);
And you are trying to assign this datum to what kind of column?
(Hint: there isn't any kind for which a plain C string is valid data.)
regards, tom lane
Thus spake Tom Lane
darcy@druid.net (D'Arcy J.M. Cain) writes:
char cardnum[48];
...
newval = CStringGetDatum(cardnum);And you are trying to assign this datum to what kind of column?
(Hint: there isn't any kind for which a plain C string is valid data.)
Right. That was just my latest try. I did notice that CStringGetDatum was
just defined as PointerGetDatum. I tried to find something specific for
text but nothing seemed to fit the bill. I saw DatumGetTextP but that
detoasts a toasted object. There were the various PG_RETURNxxx macros
but this is a user created strting, not an argument.
Do I have to manually create a varlena? I'll try that next.
--
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.darcy@druid.net (D'Arcy J.M. Cain) writes:
Do I have to manually create a varlena? I'll try that next.
The best way to get from a C string to a valid datum is to invoke the
datatype's input conversion routine. If you know you want text,
you could do
#define _textin(str) DirectFunctionCall1(textin, CStringGetDatum(str))
to produce a datum from a C string.
regards, tom lane
Thus spake Tom Lane
darcy@druid.net (D'Arcy J.M. Cain) writes:
Do I have to manually create a varlena? I'll try that next.
The best way to get from a C string to a valid datum is to invoke the
datatype's input conversion routine. If you know you want text,
you could do#define _textin(str) DirectFunctionCall1(textin, CStringGetDatum(str))
to produce a datum from a C string.
Ah, that was it. I had done a similar thing in another trigger with a
date type. I should have thought of that.
Hmm. Does this suggest more macros in fmgr.h or postgres.h?
--
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.