BUG #12126: Empty tsvector as output of to_tsvector function

The following bug has been logged on the website:

Bug reference: 12126
Logged by: Marcin Ogorzałek
Email address: marcin(dot)ogorzalek(at)jmkcomputerate(dot)pl
PostgreSQL version: 9.2.9
Operating system: Windows 7 Home Premium
Description:

Hello,

I was trying to use postgresql full text search feature but all texts used
were giving me empty tsvectors as a returned value therefore being
unusable.

I even tested part of your own documentation as stated below and it gave me
empty result as well. I'm pretty sure that returned ts_vector was not over
1MB and there were no warnings or errors. Postgres states that it
successfully returned 1 row.

Here is my statement:
select to_tsvector('
12.2. Tables and Indexes

The examples in the previous section illustrated full text matching using
simple constant strings. This section shows how to search table data,
optionally using indexes.
12.2.1. Searching a Table

It is possible to do a full text search without an index. A simple query to
print the title of each row that contains the word friend in its body field
is:

SELECT title
FROM pgweb
WHERE to_tsvector(''english'', body) @@ to_tsquery(''english'',
''friend'');

This will also find related words such as friends and friendly, since all
these are reduced to the same normalized lexeme.

The query above specifies that the english configuration is to be used to
parse and normalize the strings. Alternatively we could omit the
configuration parameters:

SELECT title
FROM pgweb
WHERE to_tsvector(body) @@ to_tsquery(''friend'');

This query will use the configuration set by default_text_search_config.

A more complex example is to select the ten most recent documents that
contain create and table in the title or body:

SELECT title
FROM pgweb
WHERE to_tsvector(title || '' '' || body) @@ to_tsquery(''create & table'')
ORDER BY last_mod_date DESC
LIMIT 10;

For clarity we omitted the coalesce function calls which would be needed to
find rows that contain NULL in one of the two fields.

Although these queries will work without an index, most applications will
find this approach too slow, except perhaps for occasional ad-hoc searches.
Practical use of text searching usually requires creating an index.
12.2.2. Creating Indexes

We can create a GIN index (Section 12.9) to speed up text searches:

CREATE INDEX pgweb_idx ON pgweb USING gin(to_tsvector(''english'', body));

Notice that the 2-argument version of to_tsvector is used. Only text search
functions that specify a configuration name can be used in expression
indexes (Section 11.7). This is because the index contents must be
unaffected by default_text_search_config. If they were affected, the index
contents might be inconsistent because different entries could contain
tsvectors that were created with different text search configurations, and
there would be no way to guess which was which. It would be impossible to
dump and restore such an index correctly.

Because the two-argument version of to_tsvector was used in the index above,
only a query reference that uses the 2-argument version of to_tsvector with
the same configuration name will use that index. That is, WHERE
to_tsvector(''english'', body) @@ ''a & b'' can use the index, but WHERE
to_tsvector(body) @@ ''a & b'' cannot. This ensures that an index will be
used only with the same configuration used to create the index entries.

It is possible to set up more complex expression indexes wherein the
configuration name is specified by another column, e.g.:

CREATE INDEX pgweb_idx ON pgweb USING gin(to_tsvector(config_name, body));

where config_name is a column in the pgweb table. This allows mixed
configurations in the same index while recording which configuration was
used for each index entry. This would be useful, for example, if the
document collection contained documents in different languages. Again,
queries that are meant to use the index must be phrased to match, e.g.,
WHERE to_tsvector(config_name, body) @@ ''a & b''.

Indexes can even concatenate columns:

CREATE INDEX pgweb_idx ON pgweb USING gin(to_tsvector(''english'', title ||
'' '' || body));

Another approach is to create a separate tsvector column to hold the output
of to_tsvector. This example is a concatenation of title and body, using
coalesce to ensure that one field will still be indexed when the other is
NULL:

ALTER TABLE pgweb ADD COLUMN textsearchable_index_col tsvector;
UPDATE pgweb SET textsearchable_index_col =
to_tsvector(''english'', coalesce(title,'''') || '' '' ||
coalesce(body,''''));

Then we create a GIN index to speed up the search:

CREATE INDEX textsearch_idx ON pgweb USING gin(textsearchable_index_col);

Now we are ready to perform a fast full text search:

SELECT title
FROM pgweb
WHERE textsearchable_index_col @@ to_tsquery(''create & table'')
ORDER BY last_mod_date DESC
LIMIT 10;

When using a separate column to store the tsvector representation, it is
necessary to create a trigger to keep the tsvector column current anytime
title or body changes. Section 12.4.3 explains how to do that.

')
---------------------------
What is intriguing is that when you delete las sentence it works great,
which means that some limit is reached. Unfortunately I can't identify it.

Apart from version metioned above i tested it on:
9.2.8 on Windows 8,
8.4.13 on Debian 6.0