From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Bug in to_tsquery(), and fix |
Date: | 2012-05-15 16:22:42 |
Message-ID: | 4FB282D2.10706@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
A customer reported a mysterious crash, with the backtrace showing it to
come from several levels down deep in the infix() function, called by
tsqueryout(). I was eventually able to reproduce this and hunt down the
bug, using the same tsquery string as the customer.
The bug was actually in to_tsquery(), and resulted in a corrupt
"operand" string being stored in a tsquery Datum. In a nutshell, in
to_tsquery_byid(), we're using memcpy() to copy to a possibly
overlapping region of data. The obvious fix is to use memmove() instead,
attached.
This is pretty hairy code, it's hard to resist doing some more whacking
around. For example the infix() function would be a lot simpler if it
used a StringInfo instead of implementing a resizeable string of its
own. But I'll leave that alone for now, given that the bug was in fact
not in that function.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
fix-to_tsquery_overlapping-memcpy.patch | text/x-diff | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2012-05-15 16:36:07 | Re: Strange issues with 9.2 pg_basebackup & replication |
Previous Message | Robert Haas | 2012-05-15 16:09:42 | Re: Why do we still have commit_delay and commit_siblings? |