tsearch2 and unexpected exists

[Nigel J. Andrews]

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

[Teodor Sigaev]

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.r u
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[Nigel J. Andrews]

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

[Andrew J. Kopciuch]

> 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

[Derrick Betts]

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 "ApplyUpdat es" 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 YourEmailAddres sHere" to ma*******@postg resql.org)

[Tom Lane]

"Derrick Betts" <De*****@griffl ink.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 "ApplyUpdat es" 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*******@postg resql.org so that your
message can get through to the mailing list cleanly

[Nigel J. Andrews]

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('i nviting');
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 getdatabaseenco ding(); 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_u ser 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 getdatabaseenco ding(); 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_u ser 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('i nviting');
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('def ault', $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.di ct_name from pg_ts_cfgmap, pg_ts_cfg, token_type( $1 ) as lt
where lt.alias = pg_ts_cfgmap.to k_alias and pg_ts_cfgmap.ts _name = pg_ts_cfg.ts_na me 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 ExecMakeFunctio nResult ()
#3 0x080d58de in ExecEvalFunc ()
#4 0x080d5f60 in ExecEvalExpr ()
#5 0x080d5111 in ExecEvalFuncArg s ()
#6 0x080d51ca in ExecMakeFunctio nResult ()
#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_ope ration ()
#18 0x080e00d4 in SPI_cursor_fetc h ()
#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_fu nction () from /usr/local/stow/postgresql-7.3.4/lib/plpgsql.so
#24 0x40a239ed in plpgsql_call_ha ndler () from /usr/local/stow/postgresql-7.3.4/lib/plpgsql.so
#25 0x080d5301 in ExecMakeFunctio nResult ()
#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_s tring ()
#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_ma in () 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('def ault', '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*******@postg resql.org so that your
message can get through to the mailing list cleanly

[Nigel J. Andrews]

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

[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(''de fault'', $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 YourEmailAddres sHere" to ma*******@postg resql.org)

[Nigel J. Andrews]

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=0x82b2 8f0) at mcxt.c:480
#1 0x40a4f93c in to_tsquery_name (fcinfo=0xbfffe 590) at query.c:840
#2 0x080d53f6 in ExecMakeFunctio nResult (fcache=0x82b3c b8, arguments=0x82b 2908, econtext=0x82b3 1f0, isNull=0xbfffe7 d1 "",
isDone=0xbfffe6 ec) at execQual.c:839
#3 0x080d58ee in ExecEvalFunc (funcClause=0x8 2b2878, econtext=0x82b3 1f0, isNull=0xbfffe7 d1 "", isDone=0xbfffe6 ec)
at execQual.c:1167
#4 0x080d5f70 in ExecEvalExpr (expression=0x8 2b2878, econtext=0x82b3 1f0, isNull=0xbfffe7 d1 "", isDone=0xbfffe6 ec)
at execQual.c:1715
#5 0x080d5121 in ExecEvalFuncArg s (fcinfo=0xbfffe 740, argList=0x82b28 60, econtext=0x82b3 1f0) at execQual.c:624
#6 0x080d51da in ExecMakeFunctio nResult (fcache=0x82b32 80, arguments=0x82b 2860, econtext=0x82b3 1f0, isNull=0xbfffe8 8f "",
isDone=0x0) at execQual.c:680
#7 0x080d5896 in ExecEvalOper (opClause=0x82b 27e8, econtext=0x82b3 1f0, isNull=0xbfffe8 8f "", isDone=0x0) at execQual.c:1125
#8 0x080d5f60 in ExecEvalExpr (expression=0x8 2b27e8, econtext=0x82b3 1f0, isNull=0xbfffe8 8f "", isDone=0x0)
at execQual.c:1711
#9 0x080d60d6 in ExecQual (qual=0x82b2990 , econtext=0x82b3 1f0, resultForNull=0 '\0') at execQual.c:1885
#10 0x080d65c3 in ExecScan (node=0x82b2440 , accessMtd=0x80d c6d0 <SeqNext>) at execScan.c:124
#11 0x080dc77e in ExecSeqScan (node=0x82b2440 ) at nodeSeqscan.c:1 33
#12 0x080d4389 in ExecProcNode (node=0x82b2440 , parent=0x82b20d 8) 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=0x82b2e 60, plan=0x82b20d8, operation=CMD_S ELECT, numberTuples=10 ,
direction=Forwa rdScanDirection , destfunc=0x81f6 148) at execMain.c:958
#16 0x080d29c0 in ExecutorRun (queryDesc=0x82 b2e38, estate=0x82b2e6 0, direction=Forwa rdScanDirection , count=10)
at execMain.c:195
#17 0x080e0aa5 in _SPI_cursor_ope ration (portal=0x82925 08, forward=1, count=10, dest=SPI) at spi.c:1417
#18 0x080e00e4 in SPI_cursor_fetc h (portal=0x82925 08, forward=1, count=10) at spi.c:860
#19 0x40a272d8 in exec_stmt_fors (estate=0xbfffe c84, stmt=0x82a0810) at pl_exec.c:1339
#20 0x40a26c01 in exec_stmt (estate=0xbfffe c84, stmt=0x82a0810) at pl_exec.c:914
#21 0x40a26a95 in exec_stmts (estate=0xbfffe c84, stmts=0x82a0830 ) at pl_exec.c:858
#22 0x40a269eb in exec_stmt_block (estate=0xbfffe c84, block=0x82a0998 ) at pl_exec.c:814
---Type <return> to continue, or q <return> to quit---
#23 0x40a25fba in plpgsql_exec_fu nction (func=0x82a0040 , fcinfo=0xbfffed 50) at pl_exec.c:321
#24 0x40a23a1d in plpgsql_call_ha ndler (fcinfo=0xbfffe d50) at pl_handler.c:13 3
#25 0x080d5311 in ExecMakeFunctio nResult (fcache=0x8298a 58, arguments=0x829 8578, econtext=0x8298 7b8, isNull=0xbfffee bf "",
isDone=0xbfffee c0) at execQual.c:764
#26 0x080d58ee in ExecEvalFunc (funcClause=0x8 298590, econtext=0x8298 7b8, isNull=0xbfffee bf "", isDone=0xbfffee c0)
at execQual.c:1167
#27 0x080d5f70 in ExecEvalExpr (expression=0x8 298590, econtext=0x8298 7b8, isNull=0xbfffee bf "", isDone=0xbfffee c0)
at execQual.c:1715
#28 0x080d6269 in ExecTargetList (targetlist=0x8 2985b8, nodomains=1, targettype=0x82 98800, values=0x82988b 8,
econtext=0x8298 7b8, isDone=0xbffff0 ac) at execQual.c:2058
#29 0x080d64fb in ExecProject (projInfo=0x829 8958, isDone=0xbffff0 ac) at execQual.c:2282
#30 0x080dc583 in ExecResult (node=0x82985d0 ) at nodeResult.c:16 0
#31 0x080d4369 in ExecProcNode (node=0x82985d0 , parent=0x0) at execProcnode.c: 280
#32 0x080d32ee in ExecutePlan (estate=0x82986 80, plan=0x82985d0, operation=CMD_S ELECT, numberTuples=0,
direction=Forwa rdScanDirection , destfunc=0x8298 9c8) at execMain.c:958
#33 0x080d29c0 in ExecutorRun (queryDesc=0x82 98658, estate=0x829868 0, direction=Forwa rdScanDirection , count=0)
at execMain.c:195
#34 0x0812394b in ProcessQuery (parsetree=0x82 96880, plan=0x82985d0, dest=Remote, completionTag=0 xbffff240 "")
at pquery.c:242
#35 0x08121e1d in pg_exec_query_s tring (query_string=0 x8296518, dest=Remote, parse_context=0 x828aa90) at postgres.c:838
#36 0x08122f30 in PostgresMain (argc=4, argv=0xbffff490 , username=0x8256 401 "cda") at postgres.c:2013
#37 0x0810a8fa in DoBackend (port=0x82562d0 ) at postmaster.c:23 10
#38 0x0810a1ef in BackendStartup (port=0x82562d0 ) at postmaster.c:19 32
#39 0x0810936c in ServerLoop () at postmaster.c:10 09
#40 0x08108ec3 in PostmasterMain (argc=1, argv=0x8235bb0) at postmaster.c:78 8
#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_AR GS) 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_AR GS) {
text *name=PG_GETARG _TEXT_P(0);
Datum res= DirectFunctionC all2(
to_tsquery,
Int32GetDatum( name2id_cfg(nam e) ),
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 YourEmailAddres sHere" to ma*******@postg resql.org)