ERROR: Memory exhausted in AllocSetAlloc(909324558)

From: darcy(at)druid(dot)net (D'Arcy J(dot)M(dot) Cain)
To: pgsql-hackers(at)PostgreSQL(dot)org
Subject: ERROR: Memory exhausted in AllocSetAlloc(909324558)
Date: 2001-06-08 13:07:05
Message-ID: 20010608130705.EF0921A8E@druid.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at){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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jean-Francois Leveque 2001-06-08 13:21:56 Need information about Foreign Key created Triggers
Previous Message Dale Johnson 2001-06-08 09:19:49 Re: Re: REPLACE INTO table a la mySQL