Обсуждение: 1d,1e,1f poison for data?

Hello

I have inserted texts with hex codes 1d, 1e and 1f into 6.5.1 and it seems
to that this characters totaly confuses the server, the vacuum writes that
the parent for record does not exist or that the record is to long.

Is that possible?
I am not sure that this is the reason but when I copy the table to file,
destroy it, created again a copy back through filter which removes those
characters, then the server workes well. 

Should'n the data be parsed for such a character before they are inserted?

Thanks in advance
Richard Bouska 

Richard Bouska <xbouska@bsdi.infima.cz> writes:
> I have inserted texts with hex codes 1d, 1e and 1f into 6.5.1 and it seems
> to that this characters totaly confuses the server, the vacuum writes that
> the parent for record does not exist or that the record is to long.

> Is that possible?

Doesn't seem like that should be a problem (and a quick trial here
doesn't show any obvious trouble).  I'm guessing the explanation is
something else ... but I'm not sure what.

There are a couple of known gotchas that might cause trouble at vacuum
time:

1. If you run the server with different LOCALE settings at different
times, then the sort order of an existing index might be wrong for
the current LOCALE, in which case the system gets very confused.  
Don't do that ;-)

2. If you have an index on a text field, the effective limit on text
length is ~4K instead of ~8K, because the btree index code expects to be
able to fit at least 2 keys on a disk page.  This one is nasty because
if only a few of your entries are >4K you might sail along happily
until one day two long entries chance to wind up on the same page of the
index.  In particular, VACUUM rearranges the index so the problem could
show up at that time.

If neither of those explain your trouble, please see if you can
develop a reproducible test case, and submit a full bug report.
        regards, tom lane