Question

我正在对pgAdmin进行查询，并偶然发现了这种奇怪的行为我连接到运行PostgreSQL 9.1.9的服务器我有一个名为messages的表，其定义如下：

ghareh@godot:~$ psql
psql (9.1.9)
Type "help" for help.

ghareh=# \d messages
                            Table "public.messages"
    Column     |            Type             |            Modifiers            
---------------+-----------------------------+---------------------------------
 messageid     | character varying(200)      | not null
 senderaliasid | integer                     | not null
 referenceid   | character varying(200)      | default NULL::character varying
 recipaliasid  | integer                     | 
 datetime      | timestamp(2) with time zone | not null
 subject       | character varying(512)      | not null
 body          | text                        | not null
 listid        | integer                     | 
Indexes:
    "messages_pkey" PRIMARY KEY, btree (messageid)
    "messages_datetime_idx" btree (datetime)
    "recipaliasid_idx" btree (recipaliasid)
    "referenceid_idx" btree (referenceid)
    "senderaliasid_idx" btree (senderaliasid)
Foreign-key constraints:
    "messages_listid_fkey" FOREIGN KEY (listid) REFERENCES lists(listid)
    "messages_recip_fkey" FOREIGN KEY (recipaliasid, listid) REFERENCES aliases(aliasid, listid)
    "messages_sender_fkey" FOREIGN KEY (senderaliasid, listid) REFERENCES aliases(aliasid, listid)
Referenced by:
    TABLE "messages_attachments" CONSTRAINT "pkfkmid" FOREIGN KEY (messageid) REFERENCES messages(messageid)

我的问题涉及列body和subject。

我有一个生成一组结果的查询。然后，为了优化我的查询，我添加了术语：where body like '%JSON%'，即结果的子集，其中body包含字符串＆＃39; JSON＆＃39;。
我得到了一些包含这个词的结果，有些则没有！但是，如果我搜索任意字符串，结果就可以了。我查了一下，发现查询不只是搜索正文列，还有主题列，这也很疯狂。

这是我的初步查询：

select * from messages where messageid = '44BC310F.1090305@torrez.us'

返回1行：

messageid: "44BC310F.1090305@torrez.us";
senderaliasid: 13777;
referenceid: "7edfeeef0607171746r7d708067g15c77c3aa0ef9158@mail.gmail.com";
recipaliasid: ;
datetime: "2006-07-17 20:53:35-07";
listid: 251;
subject: "Re: svn commit: r422930 - /incubator/abdera/java/trunk/extensions/src/main/java/org/apache/abdera/ext/json/JSONWriter.java";
body: "busted! thanks for the thorough review.


-Elias

Garrett Rooney wrote:
> On 7/17/06, eliast@apache.org <eliast@apache.org> wrote:
>> Author: eliast
>> Date: Mon Jul 17 17:44:10 2006
>> New Revision: 422930
>>
>> URL: http://svn.apache.org/viewvc?rev=422930 (...)"

如果我搜索：

select * from messages
where messageid = '44BC310F.1090305@torrez.us'
and body like '%JSON%'

我不应该得到任何结果，因为身体里没有。但是我仍然会返回相同的行 - 这似乎是因为＆＃39; JSON＆＃39;在subject？

我甚至试过这个：

select * from messages
where messageid = '44BC310F.1090305@torrez.us'
and body like '%incubator/abdera/java/trunk/extensions/src/main/java/org/apache/abdera/ext/json/JSONWriter.java%'

我仍然有同样的行。我非常困惑。

我试图在sqlfiddle.com上重现结果，但我没有成功。在那里，我得到了sql select查询的预期：
http://sqlfiddle.com/#!1/ec74c/4

Answer 1

您无法在SQL Fiddle上重现相同的效果。

我在Postgres 9.1.13（always upgrade to the latest point release!）中重新创建了表格，并在pgAdmin（当前版本1.18.1）中运行了查询。 我无法重现这个问题。

pgAdmin的？

我不知道pgAdmin如何在这方面发挥作用 - 除非您只选择了部分查询，否则不知道此效果：
pgAdmin shortcuts to execute scripts

或者您可能会被“每列最多字符数”设置所欺骗，该设置会截断显示中的长值，将匹配隐藏在截断的部分中，如@IMSoP suggested in his comment。检查File -> Options ...

pgAdmin option

如果不是这样，除非我们处理你的问题中没有的拼写错误或情况，否则这表明数据库中存在某些内容。

腐败？

在只有一个损坏的索引的简单情况下，REINDEX TABLE可能会起作用：

REINDEX TABLE messages;

然而，仔细看，我没有看到一个可能成为罪魁祸首的指数。

系统目录损坏了吗？ 首先阅读：
http://wiki.postgresql.org/wiki/Corruption

然后阅读Notes section for REINDEX并从shell运行：

$ export PGOPTIONS="-P"
$ psql broken_db
...
broken_db=> REINDEX DATABASE broken_db;
broken_db=> \q

腐败通常表示您的硬件出现问题。失败的磁盘或其他东西。跟进......

相关问题：
Repair Corrupt database postgresql

Answer 2

在这种情况下，这是pgAdmin的错。正如@IMSoP所提到的，似乎pgAdmin截断了结果。自从我最近安装了新版本的pgAdmin后，我感到很困惑，这个行为是这个版本的新功能（默认情况下至少是新版本），因为我清楚地记得1年前运行相同的查询并获得全文结果。

pgAdmin III的错误行为？

2 个答案:

pgAdmin的？

腐败？