Обсуждение: BUG #2594: Gin Indexes cause server to crash on Windows

The following bug has been logged online:

Bug reference:      2594
Logged by:          Gin Indexes cause server to crash on Windows
Email address:      cfis@savagexi.com
PostgreSQL version: 8.2 CVS-Aug 28
Operating system:   Windows XP Pro
Description:        Gin Indexes cause server to crash on Windows
Details:

Download a build 8.2 CVS Head (August 28th) on Windows XP Pro.

Create a database, load tsearch2.  Then create a table:

CREATE TABLE test (
  vector tsvector NOT NULL
);

Try building a GIN index:

CREATE INDEX idx_test_vector ON test USING gin (vector);

You'll get this error message:

server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request.

Note that the same code works on Linux.

Also, on Windows you can use a GIST index instead of a GIN index and it will
work fine.

"Gin Indexes cause server to crash on Windows" <cfis@savagexi.com> writes:
> CREATE TABLE test (
>   vector tsvector NOT NULL
> );
> CREATE INDEX idx_test_vector ON test USING gin (vector);
> server closed the connection unexpectedly

It appears that building a gin index on an empty table fails on any
platform.  I get a null pointer dereference with the following stack trace

(gdb) bt
#0  ginGetEntry (accum=0x7b03bc90, value=0x7b03bcd8, n=0x7b03bcdc)
    at ginbulk.c:251
#1  0x15f994 in ginbuild (fcinfo=0x40104d80) at gininsert.c:316
#2  0x357a70 in OidFunctionCall3 (functionId=1074810240, arg1=1074604248,
    arg2=1074631680, arg3=1074717032) at fmgr.c:1460
#3  0x17cb4c in index_build (heapRelation=0x400ee168,
    indexRelation=0x400d9400, indexInfo=0x400ee168, isprimary=0 '\000')
    at index.c:1281
#4  0x17c1a0 in index_create (heapRelationId=83433,
    indexRelationName=0x400b1698 "idx_test_vector", indexRelationId=95941,
    indexInfo=0x400ee168, accessMethodObjectId=2742, tableSpaceId=0,
    classObjectId=0x400fa5b0, reloptions=0, isprimary=0, isconstraint=0,
    allow_system_table_mods=0, skip_build=0 '\000', concurrent=0)
    at index.c:782
#5  0x1d1da0 in DefineIndex (heapRelation=0x400b16d0,
    indexRelationName=0x400b1698 "idx_test_vector", indexRelationId=0,
    accessMethodName=0x400b1700 "gin", tableSpaceName=0x0,
    attributeList=0x400b1768, predicate=0x0, rangetable=0x0, options=0x0,
    unique=0 '\000', primary=0 '\000', isconstraint=0 '\000',
    is_alter_table=0 '\000', check_rights=1, skip_build=0 '\000',
    quiet=0 '\000', concurrent=0 '\000') at indexcmds.c:439

and

(gdb) p *accum
$1 = {ginstate = 0x7b03bc18, entries = 0x0, maxdepth = 1, stack = 0x40104d78,
  stackpos = 0, allocatedMemory = 0, length = 1074717032, entryallocator = 0x0}

so it would seem that ginGetEntry() has overlooked the case that there
are no entries.

            regards, tom lane

Works great now - thanks for the quick fix.

Charlie

Teodor Sigaev wrote:
> Fixed in HEAD, thank you
>
> Tom Lane wrote:
>> "Gin Indexes cause server to crash on Windows" <cfis@savagexi.com>
>> writes:
>>> CREATE TABLE test (
>>>   vector tsvector NOT NULL
>>> );
>>> CREATE INDEX idx_test_vector ON test USING gin (vector);
>>> server closed the connection unexpectedly
>>
>> It appears that building a gin index on an empty table fails on any
>> platform.  I get a null pointer dereference with the following stack
>> trace
>

On Tue, Aug 29, 2006 at 05:13:40PM -0600, Charlie Savage <cfis@savagexi.com> wrote:

>> Tom Lane wrote:
>>
>>> It appears that building a gin index on an empty table fails on any
>>> platform.  I get a null pointer dereference with the following stack
>>> trace

> Teodor Sigaev wrote:
>
>> Fixed in HEAD, thank you

For the sake of completeness/reference: The backport for 8.1
(http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/gin_tsearch2_81.gz)
doesn't seem to have this bug, at least on a linux x86_64 machine I can
create empty gin indexes with no problem.

And the performance is sweeeet! Thanks Oleg & Teodor!

kind regards,
    bkw

Fixed in HEAD, thank you

Tom Lane wrote:
> "Gin Indexes cause server to crash on Windows" <cfis@savagexi.com> writes:
>> CREATE TABLE test (
>>   vector tsvector NOT NULL
>> );
>> CREATE INDEX idx_test_vector ON test USING gin (vector);
>> server closed the connection unexpectedly
>
> It appears that building a gin index on an empty table fails on any
> platform.  I get a null pointer dereference with the following stack trace

--
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

> For the sake of completeness/reference: The backport for 8.1
> (http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/gin_tsearch2_81.gz)
> doesn't seem to have this bug, at least on a linux x86_64 machine I can
> create empty gin indexes with no problem.

It hasn't, because 8.2 already goes forward: there is a corner case when
documents has a lot of unique words (millions) and index creation time becomes
very long. 8.2 will create index much faster in this case.

>
> And the performance is sweeeet! Thanks Oleg & Teodor!

:)

--
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

Backport also works fine on Windows and Linux x86_32 (Fedora Core 5).

Charlie

Bernhard Weisshuhn wrote:
> On Tue, Aug 29, 2006 at 05:13:40PM -0600, Charlie Savage <cfis@savagexi.com> wrote:
>
>>> Tom Lane wrote:
>>>
>>>> It appears that building a gin index on an empty table fails on any
>>>> platform.  I get a null pointer dereference with the following stack
>>>> trace
>
>> Teodor Sigaev wrote:
>>
>>> Fixed in HEAD, thank you
>
> For the sake of completeness/reference: The backport for 8.1
> (http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/gin_tsearch2_81.gz)
> doesn't seem to have this bug, at least on a linux x86_64 machine I can
> create empty gin indexes with no problem.
>
> And the performance is sweeeet! Thanks Oleg & Teodor!
>
> kind regards,
>     bkw
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly