Re: [HACKERS] 1d,1e,1f poison for data?

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