Re: IndexBuild Function call fcinfo cannot access memory

Dear Tom,

Thanks for your reply!

Actually, I already compiled the source code with "-O0" and then got those
backtraces.

The hippobuild function just starts building an index access method and it
will call hippobuildcallback to iterate each parent table tuple in its
function body.

What makes me fell very confused is that the same code works when I call
"make check" to run regression test (testing my index) but fails at running
normal PG server.

Here are the lines before and after the problematic line hippo.c 154. It is
the first line of this function and did nothing.

On the other hand, I will try to adjust my code to fit in PG 9.6 as you
suggested.

--------------------------------------
static void hippobuildcallback()
{
.....
.....
.....
*Line 148* }
*Line 149* /*
*Line 150* *This function initializes the entire Hippo. It will call
buildcallback many times.
*Line 151* */
*Line 152* Datum
*Line 153* hippobuild(PG_FUNCTION_ARGS)
*Line 154* {
*Line 155* /*
* This is some routine declarations for variables
*/
Relation heap = (Relation) PG_GETARG_POINTER(0);
Relation index = (Relation) PG_GETARG_POINTER(1);
IndexInfo *indexInfo = (IndexInfo *) PG_GETARG_POINTER(2);
IndexBuildResult *result;
double reltuples;
HippoBuildState buildstate;
Buffer buffer;
......
--------------------------------------

Any hints for this will be greatly appreciated!

Thank you very much!

Jia Yu

On Mon, Jan 23, 2017 at 2:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Jia Yu <jiayu198910(at)gmail(dot)com> writes:
> > However, these methods don't work in the normal PG server. It gave me
> > "segmentation fault"
> > ...
> > Here is my backtrace. It looks like I cannot access fcinfo. Can you help
> me
> > about this? Or just some hints? I have been struggling with this problem
> > for weeks.
>
> What's the problematic line (hippo.c:154) doing? What's before
> that in the hippobuild function?
>
> I wouldn't put much stock in the "Cannot access memory" message ... that
> just means gdb is confused, which it frequently is. But possibly
> building with -O0 would make it less confused.
>
> BTW, I gather from the reference to OidFunctionCall3Coll that you're
> using PG 9.5 or older. It'd be a good idea to switch to 9.6, which has
> noticeably cleaner indexam APIs that allow some compiler error checking
> on those calls.
>
> regards, tom lane
>