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
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 |