472,370 Members | 2,455 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,370 software developers and data experts.

tsearch2 and unexpected exists



This will be a little vague, it was last night and I can't now do the test in
that db (see below) so can't give the exact wording.

I seem to remember a report a little while ago about tsearch v2 causing
unexpected backend exit messages with 7.3.4 and now I'm getting similar
messages unpredictably and I can't find the thread in the archives either.

What I did was install tsearch2 using share/contrib/tsearch2.sql, which placed
everything into public schema. Having created the tsvector column in a table
and populated it I tried running a pretty simple function that queried that
table (joined with another) using that tsvector column in the where
clause. This gave the unexpected exits of the backend (only the one for that
connection not all). The error was something like invalid MemoryContext
allocation 0. Other attempts gave a large number instead of 0. However, the odd
thing is that the query from the function that was using tsearch2 worked
fine when I cut it from the log and pasted it into psql directly.

The function is in plpgsql, this is the stable tarball of tsearch v2 for 7.3.4
and obviously the server is 7.3.4. All running on Debian linux (woody).

Unfortunately I can't reproduce this problem without reinstalling the db, or
seeing if createlang will work, since the untsearch2.sql script failed (I was
trying to reload tsearch2.sql jsut to see) so I foolishly dropped public schema
since I stupidly thought tsearch was the only thing using it. More importantly
I don't seem to be able to find the mailing list thread that covered pretty
much this exact unexpect exit fault. So, can anyone help with a fix,
explanation or link to the relevent thread please?

Thanks,

--
Nigel J. Andrews
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 11 '05 #1
13 2723


Nigel J. Andrews wrote:

This will be a little vague, it was last night and I can't now do the test in
that db (see below) so can't give the exact wording.

I seem to remember a report a little while ago about tsearch v2 causing
unexpected backend exit messages with 7.3.4 and now I'm getting similar
messages unpredictably and I can't find the thread in the archives either.

What I did was install tsearch2 using share/contrib/tsearch2.sql, which placed
everything into public schema. Having created the tsvector column in a table
and populated it I tried running a pretty simple function that queried that
table (joined with another) using that tsvector column in the where
clause. This gave the unexpected exits of the backend (only the one for that
connection not all). The error was something like invalid MemoryContext
allocation 0. Other attempts gave a large number instead of 0. However, the odd
thing is that the query from the function that was using tsearch2 worked
fine when I cut it from the log and pasted it into psql directly.

The function is in plpgsql, this is the stable tarball of tsearch v2 for 7.3.4
and obviously the server is 7.3.4. All running on Debian linux (woody).

Unfortunately I can't reproduce this problem without reinstalling the db, or
seeing if createlang will work, since the untsearch2.sql script failed (I was
trying to reload tsearch2.sql jsut to see) so I foolishly dropped public schema
since I stupidly thought tsearch was the only thing using it. More importantly
I don't seem to be able to find the mailing list thread that covered pretty
much this exact unexpect exit fault. So, can anyone help with a fix,
explanation or link to the relevent thread please?


Have you a core file, if yes then send gdb output, pls...
--
Teodor Sigaev E-mail: te****@sigaev.ru
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 11 '05 #2
On Thu, 4 Sep 2003, Teodor Sigaev wrote:


Nigel J. Andrews wrote:

I don't seem to be able to find the mailing list thread that covered pretty
much this exact unexpect exit fault. So, can anyone help with a fix,
explanation or link to the relevent thread please?


Have you a core file, if yes then send gdb output, pls...


Hmmm...I was hoping that the previous thread would have just given me a
solution. I'll have to try and get the core file this evening as I don't
normally generate them.
--
Nigel J. Andrews
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 11 '05 #3
> What I did was install tsearch2 using share/contrib/tsearch2.sql, which
placed everything into public schema. Having created the tsvector column in
a table and populated it I tried running a pretty simple function that
queried that table (joined with another) using that tsvector column in the
where clause. This gave the unexpected exits of the backend (only the one
for that connection not all). The error was something like invalid
MemoryContext allocation 0. Other attempts gave a large number instead of
0. However, the odd thing is that the query from the function that was
using tsearch2 worked fine when I cut it from the log and pasted it into
psql directly.

The function is in plpgsql, this is the stable tarball of tsearch v2 for
7.3.4 and obviously the server is 7.3.4. All running on Debian linux
(woody).


Can you post some table definitions, and the function you used? It would be
nice to see exactly what you are attempting.

Andy

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 11 '05 #4
I am a Postgres novice. I have not done anything in the way of configuring
the DB differently from what the defaults are.

Here is my problem...
I am sending the source text from web pages to the DB (7.3.2) through a
dataset in Delphi. The field in the DB table is of the type "text", and the
fieldtype in Delphi shows ftMemo (a Blob type). When I "ApplyUpdates" from
my application I get the "SQL Error: pqReadData() -- read() failed: errno=0
No error" message.

Now, this is only happening when the length of the text that I am attempting
to update to the DB is large. On smaller text string sizes (ie. simple Web
Pages), I get no error and everything posts fine.

Is there some sort of setting that needs to be set for large "text" strings
on the DB, or is it likely to be an issue with the dataset - ApplyUpdates
procedure inside Delphi?

Thanks,
Derrick
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 11 '05 #5
"Derrick Betts" <De*****@grifflink.com> writes:
I am sending the source text from web pages to the DB (7.3.2) through a
dataset in Delphi. The field in the DB table is of the type "text", and the
fieldtype in Delphi shows ftMemo (a Blob type). When I "ApplyUpdates" from
my application I get the "SQL Error: pqReadData() -- read() failed: errno=0
No error" message. Now, this is only happening when the length of the text that I am attempting
to update to the DB is large.


Are you by any chance connecting through an SSL-encrypted connection?
If so, does the problem go away when you disable SSL? We recently found
some buffering problems in our SSL interface code that might possibly
yield this kind of failure.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 11 '05 #6
On Thu, 4 Sep 2003, Teodor Sigaev wrote:


Nigel J. Andrews wrote:

This will be a little vague, it was last night and I can't now do the test in
that db (see below) so can't give the exact wording.

I seem to remember a report a little while ago about tsearch v2 causing
unexpected backend exit messages with 7.3.4 and now I'm getting similar
messages unpredictably and I can't find the thread in the archives either.

What I did was install tsearch2 using share/contrib/tsearch2.sql, which placed
everything into public schema. Having created the tsvector column in a table
and populated it I tried running a pretty simple function that queried that
table (joined with another) using that tsvector column in the where
clause. This gave the unexpected exits of the backend (only the one for that
connection not all). The error was something like invalid MemoryContext
allocation 0. Other attempts gave a large number instead of 0. However, the odd
thing is that the query from the function that was using tsearch2 worked
fine when I cut it from the log and pasted it into psql directly.

The function is in plpgsql, this is the stable tarball of tsearch v2 for 7.3.4
and obviously the server is 7.3.4. All running on Debian linux (woody).

Unfortunately I can't reproduce this problem without reinstalling the db, or
seeing if createlang will work, since the untsearch2.sql script failed (I was
trying to reload tsearch2.sql jsut to see) so I foolishly dropped public schema
since I stupidly thought tsearch was the only thing using it. More importantly
I don't seem to be able to find the mailing list thread that covered pretty
much this exact unexpect exit fault. So, can anyone help with a fix,
explanation or link to the relevent thread please?


Have you a core file, if yes then send gdb output, pls...


Unfortunately it was only after getting this core file that I noticed I don't
have it built with debugging symbols. However, as a starting point, here's the
psql session that kicks the core dump, the entire log for the server (although
it's not got much debug logging enabled) and the back trace. Oh, and the psql
session showing the successful completion of the tsearch2 query logged from the
function body.

When I have data for the query to find there are actually results for
'inviting'. However, at the moment there are a thousand or so tuples in the
main table but the tsvector column is null for all of them. I noticed this
problem when I had valid data in the tsvector column used in the query, and
indeed got tuples returned for the search word used in the following logs, so
it doesn't appear to be a problem with nulls.

In the query below the pertinent details of the main table are:

id, article_id integer type,
name, summary text type
and search1 of type tsvector.

No dropped columns, in fact this is a completely new install of the db from
release scripts. The only anomoly is that tsearch2.sql was run such that SET
search_path at the top was replaced with a: set search_path tsearch2; command
and any other lines matching /SET search_path/ just deleted. However, this is
because having installed into public things got a little messy forcing me to do
this new install from release scripts and I first saw this problem with the
installation in public so it's not to do with installation schema.

I'll have to see if I can get everything rebuilt with -g :( If this is
sufficient could you let me know please, it'd save me some work and my wife is
already annoyed at how much I work.

Thanks, apart from this instability it looks good, I'm running the old tsearch
on a 7.2.x db and the version just seems nicer.
--
Nigel J. Andrews


$ psql -U cms cms_1
Welcome to psql 7.3.4, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

cms_1=> \c - cda
You are now connected as new user cda.
cms_1=> select basic_search('inviting');
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>

A fresh start of the server (to enable core dumping) so the entire log is:
2003-09-06 00:24:56 LOG: database system was shut down at 2003-09-06 00:24:54 BST
2003-09-06 00:24:56 LOG: checkpoint record is at 9/D625BBE0
2003-09-06 00:24:56 LOG: redo record is at 9/D625BBE0; undo record is at 0/0; shutdown TRUE
2003-09-06 00:24:56 LOG: next transaction id: 1408188; next oid: 2819206
2003-09-06 00:24:56 LOG: database system is ready
2003-09-06 00:25:51 LOG: connection received: host=[local]
2003-09-06 00:25:51 LOG: connection authorized: user=cms database=cms_1
2003-09-06 00:25:51 LOG: query: begin; select getdatabaseencoding(); commit
2003-09-06 00:25:51 LOG: duration: 0.002865 sec
2003-09-06 00:25:51 LOG: query: BEGIN; SELECT usesuper FROM pg_catalog.pg_user WHERE usename = 'cms'; COMMIT
2003-09-06 00:25:51 LOG: duration: 0.009513 sec
2003-09-06 00:25:54 LOG: connection received: host=[local]
2003-09-06 00:25:54 LOG: connection authorized: user=cda database=cms_1
2003-09-06 00:25:54 LOG: query: begin; select getdatabaseencoding(); commit
2003-09-06 00:25:54 LOG: duration: 0.001072 sec
2003-09-06 00:25:54 LOG: query: BEGIN; SELECT usesuper FROM pg_catalog.pg_user WHERE usename = 'cda'; COMMIT
2003-09-06 00:25:54 LOG: duration: 0.004303 sec
2003-09-06 00:25:59 LOG: query: select basic_search('inviting');
2003-09-06 00:25:59 LOG: query: SELECT ac.id ,ac.article_id ,ac.name ,ac.summary FROM article_content ac ,article_status s
WHERE ac.status_id = s.id AND s.name = 'Live' AND ac.search1 @@ to_tsquery('default', $1 )
2003-09-06 00:25:59 LOG: query: select oid from pg_ts_cfg where ts_name = $1
2003-09-06 00:25:59 LOG: query: select prs_name from pg_ts_cfg where oid = $1
2003-09-06 00:25:59 LOG: query: select lt.tokid, pg_ts_cfgmap.dict_name from pg_ts_cfgmap, pg_ts_cfg, token_type( $1 ) as lt
where lt.alias = pg_ts_cfgmap.tok_alias and pg_ts_cfgmap.ts_name = pg_ts_cfg.ts_name and pg_ts_cfg.oid= $2 order by lt.tokid
desc;
2003-09-06 00:25:59 LOG: query: select oid from pg_ts_parser where prs_name = $1
2003-09-06 00:25:59 LOG: query: select prs_start, prs_nexttoken, prs_end, prs_lextype, prs_headline from pg_ts_parser where
oid = $1
2003-09-06 00:25:59 LOG: query: select oid from pg_ts_dict where dict_name = $1
2003-09-06 00:25:59 LOG: query: select dict_init, dict_initoption, dict_lexize from pg_ts_dict where oid = $1
2003-09-06 00:25:59 LOG: server process (pid 11145) was terminated by signal 11
2003-09-06 00:25:59 LOG: terminating any other active server processes
2003-09-06 00:25:59 LOG: all server processes terminated; reinitializing shared memory and semaphores
2003-09-06 00:25:59 LOG: database system was interrupted at 2003-09-06 00:24:56 BST
2003-09-06 00:25:59 LOG: checkpoint record is at 9/D625BBE0
2003-09-06 00:25:59 LOG: redo record is at 9/D625BBE0; undo record is at 0/0; shutdown TRUE
2003-09-06 00:25:59 LOG: next transaction id: 1408188; next oid: 2819206
2003-09-06 00:25:59 LOG: database system was not properly shut down; automatic recovery in progress
2003-09-06 00:25:59 LOG: connection received: host=[local]
2003-09-06 00:25:59 FATAL: The database system is starting up
2003-09-06 00:26:01 LOG: ReadRecord: record with zero length at 9/D625BC20
2003-09-06 00:26:01 LOG: redo is not required
2003-09-06 00:26:03 LOG: database system is ready


(gdb) bt
#0 0x08173aa7 in pfree ()
#1 0x40a4f90c in to_tsquery_name () from /usr/local/stow/postgresql-7.3.4/lib/tsearch2.so
#2 0x080d53e6 in ExecMakeFunctionResult ()
#3 0x080d58de in ExecEvalFunc ()
#4 0x080d5f60 in ExecEvalExpr ()
#5 0x080d5111 in ExecEvalFuncArgs ()
#6 0x080d51ca in ExecMakeFunctionResult ()
#7 0x080d5886 in ExecEvalOper ()
#8 0x080d5f50 in ExecEvalExpr ()
#9 0x080d60c6 in ExecQual ()
#10 0x080d65b3 in ExecScan ()
#11 0x080dc76e in ExecSeqScan ()
#12 0x080d4379 in ExecProcNode ()
#13 0x080dbe27 in ExecNestLoop ()
#14 0x080d43c9 in ExecProcNode ()
#15 0x080d32de in ExecutePlan ()
#16 0x080d29b0 in ExecutorRun ()
#17 0x080e0a95 in _SPI_cursor_operation ()
#18 0x080e00d4 in SPI_cursor_fetch ()
#19 0x40a272a8 in exec_stmt_fors () from /usr/local/stow/postgresql-7.3.4/lib/plpgsql.so
#20 0x40a26bd1 in exec_stmt () from /usr/local/stow/postgresql-7.3.4/lib/plpgsql.so
#21 0x40a26a65 in exec_stmts () from /usr/local/stow/postgresql-7.3.4/lib/plpgsql.so
#22 0x40a269bb in exec_stmt_block () from /usr/local/stow/postgresql-7.3.4/lib/plpgsql.so
#23 0x40a25f8a in plpgsql_exec_function () from /usr/local/stow/postgresql-7.3.4/lib/plpgsql.so
#24 0x40a239ed in plpgsql_call_handler () from /usr/local/stow/postgresql-7.3.4/lib/plpgsql.so
#25 0x080d5301 in ExecMakeFunctionResult ()
#26 0x080d58de in ExecEvalFunc ()
#27 0x080d5f60 in ExecEvalExpr ()
#28 0x080d6259 in ExecTargetList ()
#29 0x080d64eb in ExecProject ()
#30 0x080dc573 in ExecResult ()
#31 0x080d4359 in ExecProcNode ()
#32 0x080d32de in ExecutePlan ()
#33 0x080d29b0 in ExecutorRun ()
#34 0x0812394b in ProcessQuery ()
#35 0x08121e1d in pg_exec_query_string ()
#36 0x08122f30 in PostgresMain ()
#37 0x0810a8fa in DoBackend ()
#38 0x0810a1ef in BackendStartup ()
#39 0x0810936c in ServerLoop ()
#40 0x08108ec3 in PostmasterMain ()
#41 0x080e60df in main ()
#42 0x401d814f in __libc_start_main () from /lib/libc.so.6
(gdb)

The query issued directly in psql:
You are now connected as new user cda.
cms_1=> SELECT ac.id ,ac.article_id ,ac.name ,ac.summary FROM article_content ac ,article_status s WHERE ac.status_id = s.id AND s.name = 'Live' AND ac.search1 @@ to_tsquery('default', 'inviting' );
id | article_id | name | summary
----+------------+------+---------
(0 rows)

cms_1=>

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 11 '05 #7
On Sat, 6 Sep 2003, Nigel J. Andrews wrote:
On Thu, 4 Sep 2003, Teodor Sigaev wrote:


Nigel J. Andrews wrote:

This will be a little vague, it was last night and I can't now do the test in
that db (see below) so can't give the exact wording.

I seem to remember a report a little while ago about tsearch v2 causing
unexpected backend exit messages with 7.3.4 and now I'm getting similar
messages unpredictably and I can't find the thread in the archives either.
...


Have you a core file, if yes then send gdb output, pls...


Unfortunately it was only after getting this core file that I noticed I don't
have it built with debugging symbols. However, as a starting point, here's the
psql session that kicks the core dump, the entire log for the server (although
...


Oh, one snippet I forgot to mention. I changed the permissions for the
installed tsearch bits by allowing public usage on the schema and select on the
4 tsearch2 tables contained in it. Could this be significant?
--
Nigel J. Andrews
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 11 '05 #8
On Sat, 6 Sep 2003, Nigel J. Andrews wrote:
On Sat, 6 Sep 2003, Nigel J. Andrews wrote:
On Thu, 4 Sep 2003, Teodor Sigaev wrote:


Nigel J. Andrews wrote:
>
> This will be a little vague, it was last night and I can't now do the test in
> that db (see below) so can't give the exact wording.
>
> I seem to remember a report a little while ago about tsearch v2 causing
> unexpected backend exit messages with 7.3.4 and now I'm getting similar
> messages unpredictably and I can't find the thread in the archives either.
> ...

Have you a core file, if yes then send gdb output, pls...


Unfortunately it was only after getting this core file that I noticed I don't
have it built with debugging symbols. However, as a starting point, here's the
psql session that kicks the core dump, the entire log for the server (although
...


Oh, one snippet I forgot to mention. I changed the permissions for the
installed tsearch bits by allowing public usage on the schema and select on the
4 tsearch2 tables contained in it. Could this be significant?


And it just occurred to me I didn't include the function definition before
which would be quite good considering it's perhaps the interaction between
plgpsql and tsearch2.

--
Nigel J. Andrews
Function and related definitions:

CREATE TYPE article_search AS (
article_content_id integer
,article_id integer
,name text
,summary text
);

CREATE OR REPLACE FUNCTION basic_search ( text )
RETURNS setof article_search
AS '
DECLARE
myrec article_search%ROWTYPE;
BEGIN
FOR myrec IN
SELECT
ac.id
,ac.article_id
,ac.name
,ac.summary
FROM
article_content ac
,article_status s
WHERE
ac.status_id = s.id
AND
s.name = ''Live''
AND
ac.search1 @@ to_tsquery(''default'', $1)
LOOP

RETURN NEXT myrec;
END LOOP;

RETURN;
END;
'
LANGUAGE 'plpgsql';
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 11 '05 #9

Depressing how most of the replies in the this thread are from me and now I'm
doing another one :)
On Sat, 6 Sep 2003, Nigel J. Andrews wrote:
On Sat, 6 Sep 2003, Nigel J. Andrews wrote:
On Sat, 6 Sep 2003, Nigel J. Andrews wrote:
On Thu, 4 Sep 2003, Teodor Sigaev wrote:
>
> Nigel J. Andrews wrote:
> >
> > This will be a little vague, it was last night and I can't now do the test in
> > that db (see below) so can't give the exact wording.
> >
> > I seem to remember a report a little while ago about tsearch v2 causing
> > unexpected backend exit messages with 7.3.4 and now I'm getting similar
> > messages unpredictably and I can't find the thread in the archives either.
> > ...
>
> Have you a core file, if yes then send gdb output, pls...

So I rebuilt with debugging and this is the backtrace:

(gdb) bt
#0 0x08173aa7 in pfree (pointer=0x82b28f0) at mcxt.c:480
#1 0x40a4f93c in to_tsquery_name (fcinfo=0xbfffe590) at query.c:840
#2 0x080d53f6 in ExecMakeFunctionResult (fcache=0x82b3cb8, arguments=0x82b2908, econtext=0x82b31f0, isNull=0xbfffe7d1 "",
isDone=0xbfffe6ec) at execQual.c:839
#3 0x080d58ee in ExecEvalFunc (funcClause=0x82b2878, econtext=0x82b31f0, isNull=0xbfffe7d1 "", isDone=0xbfffe6ec)
at execQual.c:1167
#4 0x080d5f70 in ExecEvalExpr (expression=0x82b2878, econtext=0x82b31f0, isNull=0xbfffe7d1 "", isDone=0xbfffe6ec)
at execQual.c:1715
#5 0x080d5121 in ExecEvalFuncArgs (fcinfo=0xbfffe740, argList=0x82b2860, econtext=0x82b31f0) at execQual.c:624
#6 0x080d51da in ExecMakeFunctionResult (fcache=0x82b3280, arguments=0x82b2860, econtext=0x82b31f0, isNull=0xbfffe88f "",
isDone=0x0) at execQual.c:680
#7 0x080d5896 in ExecEvalOper (opClause=0x82b27e8, econtext=0x82b31f0, isNull=0xbfffe88f "", isDone=0x0) at execQual.c:1125
#8 0x080d5f60 in ExecEvalExpr (expression=0x82b27e8, econtext=0x82b31f0, isNull=0xbfffe88f "", isDone=0x0)
at execQual.c:1711
#9 0x080d60d6 in ExecQual (qual=0x82b2990, econtext=0x82b31f0, resultForNull=0 '\0') at execQual.c:1885
#10 0x080d65c3 in ExecScan (node=0x82b2440, accessMtd=0x80dc6d0 <SeqNext>) at execScan.c:124
#11 0x080dc77e in ExecSeqScan (node=0x82b2440) at nodeSeqscan.c:133
#12 0x080d4389 in ExecProcNode (node=0x82b2440, parent=0x82b20d8) at execProcnode.c:291
#13 0x080dbe37 in ExecNestLoop (node=0x82b20d8) at nodeNestloop.c:128
#14 0x080d43d9 in ExecProcNode (node=0x82b20d8, parent=0x0) at execProcnode.c:314
#15 0x080d32ee in ExecutePlan (estate=0x82b2e60, plan=0x82b20d8, operation=CMD_SELECT, numberTuples=10,
direction=ForwardScanDirection, destfunc=0x81f6148) at execMain.c:958
#16 0x080d29c0 in ExecutorRun (queryDesc=0x82b2e38, estate=0x82b2e60, direction=ForwardScanDirection, count=10)
at execMain.c:195
#17 0x080e0aa5 in _SPI_cursor_operation (portal=0x8292508, forward=1, count=10, dest=SPI) at spi.c:1417
#18 0x080e00e4 in SPI_cursor_fetch (portal=0x8292508, forward=1, count=10) at spi.c:860
#19 0x40a272d8 in exec_stmt_fors (estate=0xbfffec84, stmt=0x82a0810) at pl_exec.c:1339
#20 0x40a26c01 in exec_stmt (estate=0xbfffec84, stmt=0x82a0810) at pl_exec.c:914
#21 0x40a26a95 in exec_stmts (estate=0xbfffec84, stmts=0x82a0830) at pl_exec.c:858
#22 0x40a269eb in exec_stmt_block (estate=0xbfffec84, block=0x82a0998) at pl_exec.c:814
---Type <return> to continue, or q <return> to quit---
#23 0x40a25fba in plpgsql_exec_function (func=0x82a0040, fcinfo=0xbfffed50) at pl_exec.c:321
#24 0x40a23a1d in plpgsql_call_handler (fcinfo=0xbfffed50) at pl_handler.c:133
#25 0x080d5311 in ExecMakeFunctionResult (fcache=0x8298a58, arguments=0x8298578, econtext=0x82987b8, isNull=0xbfffeebf "",
isDone=0xbfffeec0) at execQual.c:764
#26 0x080d58ee in ExecEvalFunc (funcClause=0x8298590, econtext=0x82987b8, isNull=0xbfffeebf "", isDone=0xbfffeec0)
at execQual.c:1167
#27 0x080d5f70 in ExecEvalExpr (expression=0x8298590, econtext=0x82987b8, isNull=0xbfffeebf "", isDone=0xbfffeec0)
at execQual.c:1715
#28 0x080d6269 in ExecTargetList (targetlist=0x82985b8, nodomains=1, targettype=0x8298800, values=0x82988b8,
econtext=0x82987b8, isDone=0xbffff0ac) at execQual.c:2058
#29 0x080d64fb in ExecProject (projInfo=0x8298958, isDone=0xbffff0ac) at execQual.c:2282
#30 0x080dc583 in ExecResult (node=0x82985d0) at nodeResult.c:160
#31 0x080d4369 in ExecProcNode (node=0x82985d0, parent=0x0) at execProcnode.c:280
#32 0x080d32ee in ExecutePlan (estate=0x8298680, plan=0x82985d0, operation=CMD_SELECT, numberTuples=0,
direction=ForwardScanDirection, destfunc=0x82989c8) at execMain.c:958
#33 0x080d29c0 in ExecutorRun (queryDesc=0x8298658, estate=0x8298680, direction=ForwardScanDirection, count=0)
at execMain.c:195
#34 0x0812394b in ProcessQuery (parsetree=0x8296880, plan=0x82985d0, dest=Remote, completionTag=0xbffff240 "")
at pquery.c:242
#35 0x08121e1d in pg_exec_query_string (query_string=0x8296518, dest=Remote, parse_context=0x828aa90) at postgres.c:838
#36 0x08122f30 in PostgresMain (argc=4, argv=0xbffff490, username=0x8256401 "cda") at postgres.c:2013
#37 0x0810a8fa in DoBackend (port=0x82562d0) at postmaster.c:2310
#38 0x0810a1ef in BackendStartup (port=0x82562d0) at postmaster.c:1932
#39 0x0810936c in ServerLoop () at postmaster.c:1009
#40 0x08108ec3 in PostmasterMain (argc=1, argv=0x8235bb0) at postmaster.c:788
#41 0x080e60ef in main (argc=1, argv=0xbffffe14) at main.c:210
(gdb)
(gdb) up
(gdb) p *name
$7 = {vl_len = 11, vl_dat = "d"}
(gdb) p (char *)name->vl_dat
$8 = 0x82b28f4 "default"
(gdb)

to_tsquery_name(PG_FUNCTION_ARGS) from tsearch2/query.c (below) obviously maps
to the to_tsquery(text,text) version of to_tsquery (given how the code looks
and fcinfo->flinfo->fn_oid) but, shouldn't that PG_FREE_IF_COPY be
PG_FREE_IF_COPY(name,0), note the 0 instead of 1?
Datum
to_tsquery_name(PG_FUNCTION_ARGS) {
text *name=PG_GETARG_TEXT_P(0);
Datum res= DirectFunctionCall2(
to_tsquery,
Int32GetDatum( name2id_cfg(name) ),
PG_GETARG_DATUM(1)
);

PG_FREE_IF_COPY(name,1);
PG_RETURN_DATUM(res);
}

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 11 '05 #10

On Sun, 7 Sep 2003, Nigel J. Andrews wrote:

> On Thu, 4 Sep 2003, Teodor Sigaev wrote:
> >
> > Nigel J. Andrews wrote:
> > >
> > > This will be a little vague, it was last night and I can't now do the test in
> > > that db (see below) so can't give the exact wording.
> > >
> > > I seem to remember a report a little while ago about tsearch v2 causing
> > > unexpected backend exit messages with 7.3.4 and now I'm getting similar
> > > messages unpredictably and I can't find the thread in the archives either.
> > > ...
> >
> > Have you a core file, if yes then send gdb output, pls...
... shouldn't that PG_FREE_IF_COPY be
PG_FREE_IF_COPY(name,0), note the 0 instead of 1?


My rather quick and simple testing, i.e. trying the query that was breaking
for me, now works with that change.

I've no idea how or if you're doing patches to the distribution for use with
7.3 series servers, but this looks sensible to me so I've attached a patch.

And sorry for adding to your email load recently.
--
Nigel Andrews
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 11 '05 #11


One thing that started worrying me having found what looks like a bug in
to_tsquery_name from the 7.3-stable version of tsearch v2 is the question of
bug fixes applied only to the latest [HEAD presumably] branch but not to the
7.3 stable branch.

Unfortunately I haven't managed to find the CVS repository (or cvsweb for it)
in order to check differences. Are there any? The web page given in these
mailing lists for tsearch (
http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/ ) mentioned getting the
latest v2 from cvs for postgres 7.4 but didn't give me any help finding the
repository. It may be an idea to add something there, I did check against
postgres HEAD but update and diff didn't indicate anything about tsearch2 under
contrib.

However, for me the main concern is whether the 7.3-stable branch has been
sufficiently tested for release into a production environment and as I say part
of that consideration has got to be what problems have been identified and
fixed in HEAD but not in 7.3-stable.

Given this questioning of production quality I'm considering the possibility
switching to tsearch v1 in a production environment having been using v2 if
problems do indeed arise from the use of v2. Is this really as simple as I
think it would be, i.e. loading tsearch, adding the txtidx column and adjusting
the small number of queries embedded in plpgsql functions that fill and query
the tsearch columns? I do seem to recall that tsearch v1 had some issue with
either nulls or empty strings for txtidx type, that could prove painful in any
reversion to it from v2 since it becomes difficult to empty such a column.

--
Nigel J. Andrews
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 11 '05 #12
"Nigel J. Andrews" <na******@investsystems.co.uk> writes:
One thing that started worrying me having found what looks like a bug in
to_tsquery_name from the 7.3-stable version of tsearch v2 is the question of
bug fixes applied only to the latest [HEAD presumably] branch but not to the
7.3 stable branch.
There isn't any 7.3 version of tsearch2, at least not in the community
distribution; and there won't be, because it hasn't been through a beta
test cycle. The bug you just found is exactly the sort of thing we hope
gets shaken out during beta.
Unfortunately I haven't managed to find the CVS repository (or cvsweb for it)
in order to check differences. Are there any?
The community cvsweb is at
http://developer.postgresql.org/cvsw.../pgsql-server/
I have no idea whether Oleg and Teodor are maintaining a separate one
for their 7.3 tsearch2 back-port.
However, for me the main concern is whether the 7.3-stable branch has been
sufficiently tested for release into a production environment


Surely not. tsearch2 is beta quality at this point, whether you run it
under 7.3 or 7.4. If you think its 7.3 version is somehow more stable
than the 7.4 version, you are badly mistaken.

But having said that --- you just fixed the only problem you know to
have been biting you, so why not keep running it? Software does not
magically become more stable when people aren't using it. You might
as well keep on helping to test tsearch2.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 11 '05 #13
On Sun, 7 Sep 2003, Tom Lane wrote:
"Nigel J. Andrews" <na******@investsystems.co.uk> writes:
One thing that started worrying me having found what looks like a bug in
to_tsquery_name from the 7.3-stable version of tsearch v2 is the question of
bug fixes applied only to the latest [HEAD presumably] branch but not to the
7.3 stable branch.
There isn't any 7.3 version of tsearch2, at least not in the community
distribution; and there won't be, because it hasn't been through a beta
test cycle. The bug you just found is exactly the sort of thing we hope
gets shaken out during beta.


Yes, sorry, I was refering to the version of tsearch2 labeled as being for use
in a 7.3 postgresql server as opposed to any other version of the server, like
the 7.4 in beta now. I realise that tsearch2 hadn't been through a beta cycle
on 7.3 but I'm forever an optimist. Obviously it's those bugs being found as
part of the 7.4 beta but not applied back to the version suitable for a 7.3
server that concern me now.

Unfortunately I haven't managed to find the CVS repository (or cvsweb for it)
in order to check differences. Are there any?


The community cvsweb is at
http://developer.postgresql.org/cvsw.../pgsql-server/
I have no idea whether Oleg and Teodor are maintaining a separate one
for their 7.3 tsearch2 back-port.


Ah, I see, I took it to be that tsearch2 had it's own repository somewhere. I
should have switched my brain on for this one. It looks like the 7.3 capable
version is not within the main repository (unless it just hasn't been tagged
when released).

However, for me the main concern is whether the 7.3-stable branch has been
sufficiently tested for release into a production environment


Surely not. tsearch2 is beta quality at this point, whether you run it
under 7.3 or 7.4. If you think its 7.3 version is somehow more stable
than the 7.4 version, you are badly mistaken.


No, I thought it would be the same, but obviously only if the bug fixes are
applied to both as appropiate.
But having said that --- you just fixed the only problem you know to
have been biting you, so why not keep running it?
That's why I've been thinking of still using tsearch2 but I do need to check I
can revert back to tsearch v1 quickly should there be a problem.

Software does not
magically become more stable when people aren't using it.
You might as well keep on helping to test tsearch2.


I will be doing that if I finally get around to working on an old
project. That'll be a nice test of a 7.2.x to 7.4 upgrade.
--
Nigel J. Andrews
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 11 '05 #14

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Alexander Regg | last post by:
Hi, Is it possible to get all the positions of a lexeme in a result-set of a query? For example, we have the table TEXT TEXT_IDX 'TSearch2 is...
1
by: psql-mail | last post by:
I have applied the recent tsearch2 patch and recompiled the tsearch2 module but I am still experiencing the same backend crashes as I previously described. Thanks for any help, Mat GDB...
9
by: Pavel Stehule | last post by:
Hello I try tsearch2 within czech environment. It is works fine, but I have two questions. 1. I have words "se", "ve" in my czech stop words. But I get this words in result. Why? Have I...
2
by: Fischer Ulrich | last post by:
Hi I have a problem with the restoring of a database which uses tsearch2. I made a backup as discribed in 'tsearch-v2-intro' on the tsearch2 page. Now i'm trying to restore it into a...
0
by: Markus Wollny | last post by:
Hi! Sorry to bother you, but I just don't know how to get tsearch2 configured correctly for my setup. I've got a 7.4.3 database-cluster initdb'ed with de_DE@euro as locale, the database is with...
3
by: Marcel Boscher | last post by:
Hello everybody, i tried to "J.U.S.T" install the FullTextSearchTool tsearch2 under the guidiance of : http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/...
1
by: Marcel Boscher | last post by:
Hello everybody, i'm having a hard time trying to install an i-spell dictionary into tsearch2... i do exactly as i'm being tol don the website: ...
2
by: Net Virtual Mailing Lists | last post by:
Hello, If I have a rule like this: CREATE OR REPLACE RULE sometable_update AS ON UPDATE TO table2 DO UPDATE cache SET updated_dt=NULL WHERE tablename='sometable'; CREATE OR REPLACE RULE...
7
by: Timo Haberkern | last post by:
Hi there, i have some troubles with my TSearch2 Installation. I have done this installation as described in http://www.sai.msu.su/~megera/oddmuse/index.cgi/Tsearch_V2_compound_words...
0
by: Naresh1 | last post by:
What is WebLogic Admin Training? WebLogic Admin Training is a specialized program designed to equip individuals with the skills and knowledge required to effectively administer and manage Oracle...
0
hi
by: WisdomUfot | last post by:
It's an interesting question you've got about how Gmail hides the HTTP referrer when a link in an email is clicked. While I don't have the specific technical details, Gmail likely implements measures...
1
by: Matthew3360 | last post by:
Hi, I have been trying to connect to a local host using php curl. But I am finding it hard to do this. I am doing the curl get request from my web server and have made sure to enable curl. I get a...
0
Oralloy
by: Oralloy | last post by:
Hello Folks, I am trying to hook up a CPU which I designed using SystemC to I/O pins on an FPGA. My problem (spelled failure) is with the synthesis of my design into a bitstream, not the C++...
0
by: Carina712 | last post by:
Setting background colors for Excel documents can help to improve the visual appeal of the document and make it easier to read and understand. Background colors can be used to highlight important...
0
by: Rahul1995seven | last post by:
Introduction: In the realm of programming languages, Python has emerged as a powerhouse. With its simplicity, versatility, and robustness, Python has gained popularity among beginners and experts...
1
by: Johno34 | last post by:
I have this click event on my form. It speaks to a Datasheet Subform Private Sub Command260_Click() Dim r As DAO.Recordset Set r = Form_frmABCD.Form.RecordsetClone r.MoveFirst Do If...
1
by: ezappsrUS | last post by:
Hi, I wonder if someone knows where I am going wrong below. I have a continuous form and two labels where only one would be visible depending on the checkbox being checked or not. Below is the...
0
by: jack2019x | last post by:
hello, Is there code or static lib for hook swapchain present? I wanna hook dxgi swapchain present for dx11 and dx9.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.