Skip site navigation (1) Skip section navigation (2)

Re: Fulltextindex

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fulltextindex
Date: 2002-08-30 13:44:03
Message-ID: 29881.1030715043@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> struct varlena *data;
> char    *word           = "john";
> char    *cur_pos        = NULL;
> int     cur_pos_length  = 0;

> data = (struct varlena *) palloc(VARHDRSZ + column_length + 1);
> word_length = strlen(word);
> cur_pos = &word[word_length - 2];

> while(cur_pos > word)
> {
> 	cur_pos_length = strlen(cur_pos);
> 	/* Line below causes seg fault on SECOND iteration */
> 	data->vl_len = cur_pos_length + sizeof(int32);
> 	memcpy(VARDATA(data), cur_pos, cur_pos_length);
> 	values[0] = PointerGetDatum(data);
> 	values[1] = 0;
> 	values[2] = oid;

> 	ret = SPI_execp(*(plan->splan), values, NULL, 0);
> 	if(ret != SPI_OK_INSERT)
> 		elog(ERROR, "Full Text Indexing: error executing plan in insert\n");

> 	cur_pos--;
> }

Are you sure it's actually segfaulting *at* the store into data->vl_len?
This seems hard to believe, if data is a local variable.  It seems
possible that the storage data is pointing to gets freed during
SPI_execp, but that would just mean you'd be scribbling on memory that
doesn't belong to you --- which might cause a crash later, but surely
not at that line.

It would be worth looking to see which context is active when you do the
palloc() for data, and then watch to see if anything does a
MemoryContextReset on it.  (If you are running with asserts enabled,
an even simpler test is to look and see if data->vl_len gets changed
underneath you.)

Also, I'm still wondering if column_length is guaranteed to be longer
than word_length.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-08-30 14:21:57
Subject: Re: Accessing original TupleDesc from SRF
Previous:From: Tom LaneDate: 2002-08-30 13:29:28
Subject: Re: contrib features during beta period

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group