Re: Unstable C Function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ian Campbell <ianrc72(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Unstable C Function
Date: 2016-09-22 01:29:43
Message-ID: 22218.1474507783@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ian Campbell <ianrc72(at)gmail(dot)com> writes:
> The function works fine on first call, sometimes more, then either resets
> the connection or throws this on any further calls:
> ERROR: cache lookup failed for type 0 SQL state: XX000

I think the core problem here is that you're dealing with
pass-by-reference results from the SPI_execute() --- specifically,
the int4[] "vals" values --- as if they were pass-by-value. You're
just saving the Datums, which are only pointers, and expecting what
they point to to still be good when you get around to doing
heap_form_tuple with them. But in reality they stopped being good
the moment you did SPI_finish().

The failures would be a lot less intermittent if you were testing in
a debug build (with CLOBBER_FREED_MEMORY defined).

The two basic approaches you could take that would work reliably are

1. Copy all the int4[] values into the multi_call_memory_ctx before
doing SPI_finish.

2. Instead of using multi-call mode, form all the result tuples during
a single call and return them in a tuplestore, so that all the work
is done before you call SPI_finish. You wouldn't really need the FIFO
data structure if you did it that way.

There are some other things I could criticize here, like labeling the
function IMMUTABLE when its results depend on table contents, but
they probably aren't causing your crashes.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Janes 2016-09-22 02:43:50 Re: Re: performance problems with bulk inserts/updates on tsrange with gist-based exclude constrains
Previous Message John R Pierce 2016-09-22 00:41:04 Re: json select question