Thread: RULE regression test failure
With the recent talk of RULE regression failures, I thought I'd bring back up that I _always_ have a rule failure on Freebsd/alpha. The files are attached... Chris
Attachment
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> With the recent talk of RULE regression failures, I thought I'd bring back
> up that I _always_ have a rule failure on Freebsd/alpha.
Hm, what do you get fromexplain SELECT * FROM shoe_ready WHERE total_avail >= 2;
in the regression database?
regards, tom lane
Ummmm...how do I make the regression database!? Do I have to do installcheck instead of check? Chris > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Friday, 30 August 2002 2:31 PM > To: Christopher Kings-Lynne > Cc: Hackers > Subject: Re: [HACKERS] RULE regression test failure > > > "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > With the recent talk of RULE regression failures, I thought I'd > bring back > > up that I _always_ have a rule failure on Freebsd/alpha. > > Hm, what do you get from > explain SELECT * FROM shoe_ready WHERE total_avail >= 2; > in the regression database? > > regards, tom lane >
On Fri, 30 Aug 2002, Christopher Kings-Lynne wrote: > Ummmm...how do I make the regression database!? Do I have to do > installcheck instead of check? yes Database is 'regression' g
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Ummmm...how do I make the regression database!? Do I have to do
> installcheck instead of check?
That's the easiest way; or you can restart the temp postmaster that
the regression script starts and kills.
regards, tom lane
An aside.
In the fulltextindex code I'm trying to figure out what's breaking the
attached code segment.
Basically the data->vl_len line causes a segfault on the second time thru
the while loop. I can't figure it out. I can't write to the value, but
why? Basically with a word like 'john', it is inserting 'hn', then 'ohn'
and then 'john' into the database.
Thanks for any help for me getting this in for the beta!
Chris
-------------------------------------
struct varlena *data;
char *word = NULL;
char *cur_pos = NULL;
int cur_pos_length = 0;
data = (struct varlena *) palloc(column_length);
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
executingplan in insert\n");
cur_pos--;
}
Attached. Chris > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Friday, 30 August 2002 2:31 PM > To: Christopher Kings-Lynne > Cc: Hackers > Subject: Re: [HACKERS] RULE regression test failure > > > "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > With the recent talk of RULE regression failures, I thought I'd > bring back > > up that I _always_ have a rule failure on Freebsd/alpha. > > Hm, what do you get from > explain SELECT * FROM shoe_ready WHERE total_avail >= 2; > in the regression database? > > regards, tom lane >
Attachment
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> struct varlena *data;
> char *word = NULL;
> char *cur_pos = NULL;
> int cur_pos_length = 0;
> data = (struct varlena *) palloc(column_length);
> while(cur_pos > word)
> {
> cur_pos_length = strlen(cur_pos);
> /* Line below causes seg fault on SECOND iteration */
You are not telling the whole truth here, as the above code excerpt
will obviously never iterate the WHILE even once. "NULL > NULL" is
false in every C I ever heard of.
Also, how much is column_length and how does it relate to the amount
of data being copied into *data ?
regards, tom lane
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
>> Hm, what do you get from
>> explain SELECT * FROM shoe_ready WHERE total_avail >= 2;
>> in the regression database?
>
> [this plan]
That seems substantially the same plan as I see here. I guess
that the different output order must reflect a platform-specific
difference in qsort()'s treatment of equal keys.
Probably the best answer is to add "ORDER BY shoename" to the test
query to eliminate the platform dependency. Any objections out there?
regards, tom lane
> That seems substantially the same plan as I see here. I guess > that the different output order must reflect a platform-specific > difference in qsort()'s treatment of equal keys. > > Probably the best answer is to add "ORDER BY shoename" to the test > query to eliminate the platform dependency. Any objections out there? None here. Chris
OK, I was probably a little aggressive in my pruning...BTW, this code was
not written by me...
--------------------------------
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
executingplan in insert\n");
cur_pos--;
}
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Friday, 30 August 2002 2:53 PM
> To: Christopher Kings-Lynne
> Cc: Hackers
> Subject: Re: Fulltextindex
>
>
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> > struct varlena *data;
> > char *word = NULL;
> > char *cur_pos = NULL;
> > int cur_pos_length = 0;
>
> > data = (struct varlena *) palloc(column_length);
>
> > while(cur_pos > word)
> > {
> > cur_pos_length = strlen(cur_pos);
> > /* Line below causes seg fault on SECOND iteration */
>
> You are not telling the whole truth here, as the above code excerpt
> will obviously never iterate the WHILE even once. "NULL > NULL" is
> false in every C I ever heard of.
>
> Also, how much is column_length and how does it relate to the amount
> of data being copied into *data ?
>
> regards, tom lane
>
On Fri, 30 Aug 2002, Christopher Kings-Lynne wrote:
>
> --------------------------------
>
> 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--;
> }
>
That would imply the SPI_execp call is trashing the value of data. Have you
confirmed that? (Sometimes it helps to confirm exactly where a pointer is
getting hammered.)
column_length is something sensible like word_length I presume.
That sizeof(int32) should really be VARHDRSZ imo, but I can't see how that's
breaking it.
Disclaimer: I have no idea what I'm doing here.
--
Nigel J. Andrews
"Christopher Kings-Lynne" <chriskl@familyhealth.com.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
OK, patch attached that adds ORDER BY to the problem regression query. --------------------------------------------------------------------------- Christopher Kings-Lynne wrote: > > That seems substantially the same plan as I see here. I guess > > that the different output order must reflect a platform-specific > > difference in qsort()'s treatment of equal keys. > > > > Probably the best answer is to add "ORDER BY shoename" to the test > > query to eliminate the platform dependency. Any objections out there? > > None here. > > Chris > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: src/test/regress/expected/rules.out =================================================================== RCS file: /cvsroot/pgsql-server/src/test/regress/expected/rules.out,v retrieving revision 1.62 diff -c -c -r1.62 rules.out *** src/test/regress/expected/rules.out 2 Sep 2002 02:13:02 -0000 1.62 --- src/test/regress/expected/rules.out 2 Sep 2002 04:47:26 -0000 *************** *** 1002,1008 **** sl8 | 1 | brown | 40 | inch | 101.6 (8 rows) ! SELECT * FROM shoe_ready WHERE total_avail >= 2; shoename | sh_avail | sl_name | sl_avail | total_avail ------------+----------+------------+----------+------------- sh1 | 2 | sl1 | 5 | 2 --- 1002,1008 ---- sl8 | 1 | brown | 40 | inch | 101.6 (8 rows) ! SELECT * FROM shoe_ready WHERE total_avail >= 2 ORDER BY 1; shoename | sh_avail | sl_name | sl_avail | total_avail ------------+----------+------------+----------+------------- sh1 | 2 | sl1 | 5 | 2 Index: src/test/regress/sql/rules.sql =================================================================== RCS file: /cvsroot/pgsql-server/src/test/regress/sql/rules.sql,v retrieving revision 1.21 diff -c -c -r1.21 rules.sql *** src/test/regress/sql/rules.sql 2 Sep 2002 02:13:02 -0000 1.21 --- src/test/regress/sql/rules.sql 2 Sep 2002 04:47:29 -0000 *************** *** 585,591 **** -- SELECTs in doc SELECT * FROM shoelace ORDER BY sl_name; ! SELECT * FROM shoe_ready WHERE total_avail >= 2; CREATE TABLE shoelace_log ( sl_name char(10), -- shoelace changed --- 585,591 ---- -- SELECTs in doc SELECT * FROM shoelace ORDER BY sl_name; ! SELECT * FROM shoe_ready WHERE total_avail >= 2 ORDER BY 1; CREATE TABLE shoelace_log ( sl_name char(10), -- shoelace changed
All regression tests now pass perfectly for me. Thanks. Chris > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Bruce Momjian > Sent: Monday, 2 September 2002 1:21 PM > To: Christopher Kings-Lynne > Cc: Tom Lane; Hackers > Subject: Re: [HACKERS] RULE regression test failure > > > > OK, patch attached that adds ORDER BY to the problem regression query. > > ------------------------------------------------------------------ > --------- > > Christopher Kings-Lynne wrote: > > > That seems substantially the same plan as I see here. I guess > > > that the different output order must reflect a platform-specific > > > difference in qsort()'s treatment of equal keys. > > > > > > Probably the best answer is to add "ORDER BY shoename" to the test > > > query to eliminate the platform dependency. Any objections out there? > > > > None here. > > > > Chris > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, > Pennsylvania 19073 >