tsearch2和意外存在 [英] tsearch2 and unexpected exists

问题描述

这会有点模糊，它是昨晚我现在不能在那个数据库中进行测试（见下文） ）所以不能给出确切的措辞。


我似乎记得不久之前有关tsearch v2导致

意外后端退出消息的报告7.3.4现在我得到类似的

消息无法预测，我也找不到档案中的帖子。


我做了什么是使用share / contrib / tsearch2.sql安装tsearch2，它将

所有内容放入公共模式。在表中创建了tsvector列

并填充它我尝试运行一个非常简单的函数，使用该tsvector列在哪里查询

表（与另一个表连接）

条款。这给了后端的意外退出（只有那个

连接不是全部）。错误就像无效的MemoryContext

分配0.其他尝试给出了一个很大的数字而不是0.然而，奇怪的

的事情是来自函数的查询使用tsearch2工作

当我从日志中剪切并将其直接粘贴到psql中时很好。


函数在plpgsql中，这是稳定的tarball tsearch v2 for 7.3.4

，显然服务器是7.3.4。全部在Debian linux（woody）上运行。


不幸的是，如果不重新安装数据库，我就无法重现这个问题，或者看看如果createlang能够工作，那么就可以看到这个问题。因为untsearch2.sql脚本失败了（我是试图重新加载tsearch2.sql jsut来看待b $ b）所以我愚蠢地放弃了公共模式

因为我愚蠢地认为tsearch是唯一的使用它的事情。更重要的是

我似乎无法找到覆盖相当多的邮件列表线程这个确切的意外退出故障。那么，任何人都可以帮忙修复，

解释或链接到相关主题吗？


谢谢，


-

Nigel J. Andrews

-------------------------- - （广播结束）---------------------------

提示9：规划师会忽略你的欲望如果您的

加入列的数据类型不匹配，则选择索引扫描

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

推荐答案

Nigel J. Andrews写道：

Nigel J. Andrews wrote:

这会有点模糊，它是昨晚我现在不能做的测试在那个db（见下文）中所以不能给出准确的措辞。

我似乎记得不久之前有关tsearch v2导致意外后端退出的报告带有7.3.4的消息，现在我得到了类似的消息，这些消息无法预测，我也找不到档案中的帖子。

我做的是使用share /安装tsearch2续rib / tsearch2.sql，它将所有内容放入公共模式中。在表格中创建了tsvector列并填充它后，我尝试运行一个非常简单的函数，使用where
子句中的tsvector列查询
表（与另一个表连接）。这给了后端的意外退出（只有那个
连接不是全部）。错误就像无效的MemoryContext
分配0.其他尝试给出了一个大数而不是0.然而，奇怪的是，来自使用tsearch2的函数的查询工作了很好当我从日志中剪切并直接将其粘贴到psql中时。

该函数在plpgsql中，这是tsearch v2 for 7.3.4的稳定tarball，显然服务器是7.3 0.4。所有在Debian linux（woody）上运行。

不幸的是，如果没有重新安装db，我就无法重现这个问题，或者看看createlang是否有效，因为untsearch2.sql脚本失败了（我试图重新加载tsearch2.sql jsut看看）所以我愚蠢地放弃了公共架构
因为我愚蠢地认为tsearch是唯一使用它的东西。更重要的是
我似乎无法找到覆盖相当多的邮件列表主题这个确切的意外退出错误。那么，任何人都可以帮忙修复，
解释或链接到相关的线程吗？

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?

你有一个核心文件，如果是的话然后发送gdb输出，请...

-

Teodor Sigaev电子邮件： te ** **@sigaev.ru

---------------------------（播出结束） ---------------------------

提示3：如果通过Usenet发布/阅读，请发送相应的

subscribe-nomail命令 ma*******@postgresql.org 所以您的

消息可以干净地通过邮件列表

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

2003年9月4日星期四，Teodor Sigaev写道：< br>

On Thu, 4 Sep 2003, Teodor Sigaev wrote:

Nigel J. Andrews写道：

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?

你有一个核心文件，如果是的话然后发送gdb输出，请... 。

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

嗯......我希望前一个帖子能给我一个

的解决方案。今天晚上我将不得不尝试获取核心文件，因为我通常不会产生
。

-

Nigel J. Andrews

---------------------------（播出结束）------ ---------------------

提示4：不要杀死-9''邮政局长

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

>我所做的是使用share / contrib / tsearch2.sql安装tsearch2，

> What I did was install tsearch2 using share/contrib/tsearch2.sql, which

将所有内容放入公共模式。在表中创建了tsvector列并填充它后，我尝试运行一个非常简单的函数，使用
where子句中的tsvector列查询该表（与另一个表连接）。这给了后端的意外退出（只有那个连接不是全部）。这个错误就像无效的内存一样.OninterContext分配0.其他尝试给了大量而不是
0.然而，奇怪的是来自使用tsearch2的函数的查询工作得很好当我从日志中剪切并直接粘贴到
psql中时。

该函数在plpgsql中，这是tsearch v2 for 7.3.4的稳定tarball，显然服务器是7.3.4。全部在Debian linux上运行
（woody）。

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).

你能发布一些表定义，以及你使用的函数吗？很高兴看到你正在尝试的东西很好。


Andy


----- ----------------------（播出结束）----------------------- ----

提示8：解释分析是你的朋友

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

这篇关于tsearch2和意外存在的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！