Tsearch2 Causing Backend Crash

Hmm,

it's weird. Could you provide us with backtrace ?

Oleg
On Tue, 30 Sep 2003 psql-mail@freeuk.com wrote:

After applying the patches supplied so far and also trying the lastest
stable tar.gz for tsearch2 ( downloaded 24th of september)

I am still experiencing the same issue as previously described:
I try to do a

SELECT to_tsvector( 'default', 'some text' )

The backend crashes.

SELECT to_tsvector( 'default', <string of whitespace> )
does not crash

Any more advice or suggestions?

Thanks!

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

On Fri, 3 Oct 2003, Oleg Bartunov wrote:

Hmm,

it's weird. Could you provide us with backtrace ?

Bear in mind the last patch should have fixed the specific point of failure but
something, possibly tsearch2 possibly something else, was obviously pushing the
process's memory requirements upto/beyond what the kernel was prepared or able
to assign to it.

On Tue, 30 Sep 2003 psql-mail@freeuk.com wrote:

After applying the patches supplied so far and also trying the lastest
stable tar.gz for tsearch2 ( downloaded 24th of september)

I am still experiencing the same issue as previously described:
I try to do a

SELECT to_tsvector( 'default', 'some text' )

The backend crashes.

SELECT to_tsvector( 'default', <string of whitespace> )
does not crash

Any more advice or suggestions?

As Oleg says, another back trace would be good. Perhaps the postgres.conf
settings for memory and the resource limits applied to the backend by the
system.

A small test case would help, I think you have changed from the default
dictionary for example.

I get:

=> select to_tsvector('default', 'some text');
to_tsvector
-------------
'text':2
(1 row)

for the default setup.

--
Nigel Andrews

On Fri, 2003-10-03 at 15:56, Oleg Bartunov wrote:

Hmm,

it's weird. Could you provide us with backtrace ?

Oleg

<SNIP original posting>

Oleg,
Here is the backtrace you requested, it seems unusually sort?
Gdb output:

Core was generated by `postgres: mat ts2 [local] SELECT'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libreadline.so.4...done.
Loaded symbols for /usr/lib/libreadline.so.4
Reading symbols from /lib/libtermcap.so.2...done.
Loaded symbols for /lib/libtermcap.so.2
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libm.so.6.1...done.
Loaded symbols for /lib/tls/libm.so.6.1
Reading symbols from /lib/tls/libc.so.6.1...done.
Loaded symbols for /lib/tls/libc.so.6.1
Reading symbols from /lib/ld-linux-ia64.so.2...done.
Loaded symbols for /lib/ld-linux-ia64.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/local/pgsql/lib/tsearch2.so...done.
Loaded symbols for /usr/local/pgsql/lib/tsearch2.so
#0 SN_create_env (S_size=0, I_size=2, B_size=1) at api.c:6
6 z->p = create_s();
(gdb) bt
#0 SN_create_env (S_size=0, I_size=2, B_size=1) at api.c:6
#1 0x2000000041caa870 in SN_create_env (S_size=1103944648,
I_size=1103684000, B_size=1034) at api.c:6
(gdb)