From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | gav <gav(at)nlr(dot)ru> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Re[2]: SPI_getvalue problem |
Date: | 2001-01-29 06:33:06 |
Message-ID: | 20475.980749986@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alex Guryanow <gav(at)nlr(dot)ru> writes:
> You have right. One of the values passed to SPI_getvalue is NULL. This is second parameter
> (tupdesc). But why on Linux it is not NULL, and on Solaris is?
> Here is part of my trigger-code:
> rel = CurrentTriggerData->tg_relation;
> trigtuple = CurrentTriggerData->tg_trigtuple;
> newtuple = CurrentTriggerData->tg_newtuple;
> tupdesc = rel->rd_att;
> elog(DEBUG, "before 1 SPI");
> elog(DEBUG, "triggered for relation %s", SPI_getrelname(CurrentTriggerData->tg_relation) );
> id = atoi( SPI_getvalue( trigtuple, tupdesc, 1 ) );
> elog( DEBUG, "before 1.5 SPI" ); // !!! this isn't called in Solaris
Are you sure that rel->rd_att is null? That seems extremely improbable.
What I think is more likely is that the first column of the tuple
contains a SQL NULL, and consequently SPI_getvalue returns a NULL
pointer. You are passing that NULL to atoi() without any check.
I'm not sure what Linux' atoi() does on NULL input, but a coredump
on Solaris is very believable ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Guryanow | 2001-01-29 06:43:01 | Re[4]: SPI_getvalue problem |
Previous Message | Thomas T. Thai | 2001-01-29 06:31:35 | while vacuum: pq_flush: send() failed: Broken pipe |