Thread: 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
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: teodor@sigaev.ru
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
> 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
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
"Derrick Betts" <Derrick@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
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_statuss
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 )
aslt
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=>
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
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';
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);
}
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
Attachment
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
"Nigel J. Andrews" <nandrews@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/cvsweb.cgi/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
On Sun, 7 Sep 2003, Tom Lane wrote: > "Nigel J. Andrews" <nandrews@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/cvsweb.cgi/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