Обсуждение: BUG #3767: tsearch2 index creation fatal crash
The following bug has been logged online: Bug reference: 3767 Logged by: Thomas Haegi Email address: me@alternize.com PostgreSQL version: 8.3b3 Operating system: Windows 2003 Description: tsearch2 index creation fatal crash Details: the previously reported problem gets worse if you execute the query 2-3 times... postgres.exe terminates: Faulting application postgres.exe, version 8.3.0.7319, faulting module postgres.exe, version 8.3.0.7319, fault address 0x001ced2f. from the pgsql logs: 2007-11-21 03:24:40 CET LOG: server process (PID 2376) exited with exit code 128 2007-11-21 03:24:40 CET LOG: terminating any other active server processes 2007-11-21 03:24:40 CET WARNING: terminating connection because of crash of another server process 2007-11-21 03:24:40 CET DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2007-11-21 03:24:40 CET HINT: In a moment you should be able to reconnect to the database and repeat your command. 2007-11-21 03:24:40 CET WARNING: terminating connection because of crash of another server process 2007-11-21 03:24:40 CET DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2007-11-21 03:24:40 CET HINT: In a moment you should be able to reconnect to the database and repeat your command. 2007-11-21 03:24:40 CET WARNING: terminating connection because of crash of another server process 2007-11-21 03:24:40 CET DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2007-11-21 03:24:40 CET HINT: In a moment you should be able to reconnect to the database and repeat your command. 2007-11-21 03:24:40 CET WARNING: terminating connection because of crash of another server process 2007-11-21 03:24:40 CET DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2007-11-21 03:24:40 CET HINT: In a moment you should be able to reconnect to the database and repeat your command. 2007-11-21 03:24:40 CET WARNING: terminating connection because of crash of another server process 2007-11-21 03:24:40 CET DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2007-11-21 03:24:40 CET HINT: In a moment you should be able to reconnect to the database and repeat your command. 2007-11-21 03:24:40 CET WARNING: terminating connection because of crash of another server process 2007-11-21 03:24:40 CET DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2007-11-21 03:24:40 CET HINT: In a moment you should be able to reconnect to the database and repeat your command. 2007-11-21 03:24:40 CET LOG: all server processes terminated; reinitializing 2007-11-21 03:24:41 CET FATAL: pre-existing shared memory block is still in use 2007-11-21 03:24:41 CET HINT: Check if there are any old server processes still running, and terminate them.
the reported problem below can be reproduced by using this simple query
straight from the documentation:
SELECT to_tsvector('a fat cat sat on a mat and ate a fat rat');
--> postgres.exe dies instantly, with the logs being the same as in the
bugreport.
interestingly using ::tsvector (which according to the documentation is
equivalent) works just fine:
SELECT 'a fat cat sat on a mat and ate a fat rat'::tsvector;
gives the correct result.
default configuration for text search is set to:
default_text_search_config = 'pg_catalog.german'
- thomas
-------- Original Message --------
Subject: [BUGS] BUG #3767: tsearch2 index creation fatal crash
From: Thomas Haegi <me@alternize.com>
To: pgsql-bugs@postgresql.org
Date: 21.11.2007 03:25
> The following bug has been logged online:
>
> Bug reference: 3767
> Logged by: Thomas Haegi
> Email address: me@alternize.com
> PostgreSQL version: 8.3b3
> Operating system: Windows 2003
> Description: tsearch2 index creation fatal crash
> Details:
>
> the previously reported problem gets worse if you execute the query 2-3
> times... postgres.exe terminates:
>
> Faulting application postgres.exe, version 8.3.0.7319, faulting module
> postgres.exe, version 8.3.0.7319, fault address 0x001ced2f.
>
> from the pgsql logs:
>
> 2007-11-21 03:24:40 CET LOG: server process (PID 2376) exited with exit
> code 128
> 2007-11-21 03:24:40 CET LOG: terminating any other active server processes
> 2007-11-21 03:24:40 CET WARNING: terminating connection because of crash of
> another server process
> 2007-11-21 03:24:40 CET DETAIL: The postmaster has commanded this server
> process to roll back the current transaction and exit, because another
> server process exited abnormally and possibly corrupted shared memory.
> 2007-11-21 03:24:40 CET HINT: In a moment you should be able to reconnect
> to the database and repeat your command.
> 2007-11-21 03:24:40 CET WARNING: terminating connection because of crash of
> another server process
> 2007-11-21 03:24:40 CET DETAIL: The postmaster has commanded this server
> process to roll back the current transaction and exit, because another
> server process exited abnormally and possibly corrupted shared memory.
> 2007-11-21 03:24:40 CET HINT: In a moment you should be able to reconnect
> to the database and repeat your command.
> 2007-11-21 03:24:40 CET WARNING: terminating connection because of crash of
> another server process
> 2007-11-21 03:24:40 CET DETAIL: The postmaster has commanded this server
> process to roll back the current transaction and exit, because another
> server process exited abnormally and possibly corrupted shared memory.
> 2007-11-21 03:24:40 CET HINT: In a moment you should be able to reconnect
> to the database and repeat your command.
> 2007-11-21 03:24:40 CET WARNING: terminating connection because of crash of
> another server process
> 2007-11-21 03:24:40 CET DETAIL: The postmaster has commanded this server
> process to roll back the current transaction and exit, because another
> server process exited abnormally and possibly corrupted shared memory.
> 2007-11-21 03:24:40 CET HINT: In a moment you should be able to reconnect
> to the database and repeat your command.
> 2007-11-21 03:24:40 CET WARNING: terminating connection because of crash of
> another server process
> 2007-11-21 03:24:40 CET DETAIL: The postmaster has commanded this server
> process to roll back the current transaction and exit, because another
> server process exited abnormally and possibly corrupted shared memory.
> 2007-11-21 03:24:40 CET HINT: In a moment you should be able to reconnect
> to the database and repeat your command.
> 2007-11-21 03:24:40 CET WARNING: terminating connection because of crash of
> another server process
> 2007-11-21 03:24:40 CET DETAIL: The postmaster has commanded this server
> process to roll back the current transaction and exit, because another
> server process exited abnormally and possibly corrupted shared memory.
> 2007-11-21 03:24:40 CET HINT: In a moment you should be able to reconnect
> to the database and repeat your command.
> 2007-11-21 03:24:40 CET LOG: all server processes terminated;
> reinitializing
> 2007-11-21 03:24:41 CET FATAL: pre-existing shared memory block is still in
> use
> 2007-11-21 03:24:41 CET HINT: Check if there are any old server processes
> still running, and terminate them.
>
> ---------------------------(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
"Thomas H." <me@alternize.com> writes:
> the reported problem below can be reproduced by using this simple query
> straight from the documentation:
> SELECT to_tsvector('a fat cat sat on a mat and ate a fat rat');
Works for me:
u=# set default_text_search_config = 'pg_catalog.german';
SET
u=# SELECT to_tsvector('a fat cat sat on a mat and ate a fat rat');
to_tsvector
-------------------------------------------------------------------------------
'a':1,6,10 'on':5 'and':8 'ate':9 'cat':3 'fat':2,11 'mat':7 'rat':12 'sat':4
(1 row)
regards, tom lane
>> the reported problem below can be reproduced by using this simple query
>> straight from the documentation:
>
>> SELECT to_tsvector('a fat cat sat on a mat and ate a fat rat');
>
> Works for me:
>
> u=# set default_text_search_config = 'pg_catalog.german';
> SET
> u=# SELECT to_tsvector('a fat cat sat on a mat and ate a fat rat');
> to_tsvector
> -------------------------------------------------------------------------------
> 'a':1,6,10 'on':5 'and':8 'ate':9 'cat':3 'fat':2,11 'mat':7 'rat':12 'sat':4
> (1 row)
>
even when implicitly setting default_text_search_config before the query
as you did, it fails (but gives a slightly different error message):
ERROR: translation from wchar_t to server encoding failed: No such file
or directory
maybe win32 / file paths related?
there are more problems with tsvectors. this also fails:
SELECT ' just a test: 123 '::tsvector;
ERROR: syntax error in tsvector: " just a test: 123 "
********** Error **********
ERROR: syntax error in tsvector: " just a test: 123 "
SQL state: 42601
without ":" it works:
SELECT ' just a test 123 '::tsvector;
regards, thomas
"Thomas H." <me@alternize.com> writes:
> there are more problems with tsvectors. this also fails:
> SELECT ' just a test: 123 '::tsvector;
> ERROR: syntax error in tsvector: " just a test: 123 "
That's not a bug; your input isn't valid tsvector syntax.
regards, tom lane
>> there are more problems with tsvectors. this also fails: > >> SELECT ' just a test: 123 '::tsvector; >> ERROR: syntax error in tsvector: " just a test: 123 " > > That's not a bug; your input isn't valid tsvector syntax. > ok. after re-reading page http://www.postgresql.org/docs/8.3/static/textsearch-intro.html#TEXTSEARCH-SEARCHES i saw my mistake. i misinterpreted the examples to show the possibility to convert *any* text by using casting to tsvector as an alternative to using to_tsvector :) to new tsearch-users, it might not be obvious clear that you can't just cast any text but should use to_tsvector. the example string 'a fat cat sat on a mat and ate a fat rat' looks like an normal "random" text string, especially when a tsvector in psql looks like 'ate':9 'cat':3 'fat':2,11 'mat':7 'rat':12 'sat':4 and doesn't contain stopwords like "a" and "and", which are included in the casted string... maybe an additional example that shows the usage of to_tsvector for any input string would help... thanks, thomas
"Thomas H." <me@alternize.com> writes:
> i saw my mistake. i misinterpreted the examples to show the possibility
> to convert *any* text by using casting to tsvector as an alternative to
> using to_tsvector :)
Yeah, the examples in section 12.1.2 are not actually good practice:
both sides of the match should usually get normalized before comparison,
and these examples don't do that.
I'm not sure that putting in to_tsvector calls there would be an
improvement, though, since at that point we haven't introduced
to_tsvector.
Thoughts anyone?
regards, tom lane
Tom Lane wrote: > "Thomas H." <me@alternize.com> writes: > > i saw my mistake. i misinterpreted the examples to show the possibility > > to convert *any* text by using casting to tsvector as an alternative to > > using to_tsvector :) > > Yeah, the examples in section 12.1.2 are not actually good practice: > both sides of the match should usually get normalized before comparison, > and these examples don't do that. > > I'm not sure that putting in to_tsvector calls there would be an > improvement, though, since at that point we haven't introduced > to_tsvector. > > Thoughts anyone? Yep, I saw that chicken and egg problem in the docs when I was reviewing it long ago. I never came up with a solution either. We would have to introduce configurations a lot earlier, but how would you explain them when you don't know what a tsvector is. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> I'm not sure that putting in to_tsvector calls there would be an
>> improvement, though, since at that point we haven't introduced
>> to_tsvector.
>>
>> Thoughts anyone?
> Yep, I saw that chicken and egg problem in the docs when I was reviewing
> it long ago. I never came up with a solution either.
OTOH, I see that the very next sentence mentions to_tsquery without
defining it. So maybe it wouldn't be materially less readable if we
just changed the examples to use to_tsquery and to_tsvector instead
of literal-casting. Either way, there is something going on that
doesn't meet the eye, and we might as well write an example that is
actually OK practice rather than bad practice.
regards, tom lane
>> I'm not sure that putting in to_tsvector calls there would be an >> improvement, though, since at that point we haven't introduced >> to_tsvector. Uh ... wait a moment ... stop the presses. Thomas is looking at beta1 documentation. CVS HEAD handles this a bit better I think: http://developer.postgresql.org/pgdocs/postgres/textsearch-intro.html#TEXTSEARCH-MATCHING So the first thing is to go bug the www team about updating the online 8.3beta docs, which I shall do forthwith. regards, tom lane