Re: Re[2]: SPI_getvalue problem

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re[2]: SPI_getvalue problem
Дата
Msg-id 20475.980749986@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re[2]: SPI_getvalue problem  (Alex Guryanow <gav@nlr.ru>)
Ответы Re[4]: SPI_getvalue problem
Список pgsql-general
Alex Guryanow <gav@nlr.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

В списке pgsql-general по дате отправления:

Предыдущее
От: "Thomas T. Thai"
Дата:
Сообщение: while vacuum: pq_flush: send() failed: Broken pipe
Следующее
От: Alex Guryanow
Дата:
Сообщение: Re[4]: SPI_getvalue problem