Re:

I meant a probable conversion step to some normalized Unicode
representation, as some characters in Unicode may be represented in more
than one way (e.g. NFD). But I did not have any strong evidence to support
it, that was just a wild guess.

How to investigate it further? What was the cause of index corruption? How
to prevent it in the future?

вт, 24 сент. 2019 г. в 18:48, Peter Geoghegan <pg(at)bowt(dot)ie>:

> On Tue, Sep 24, 2019 at 6:25 PM Vladimir Ryabtsev <greatvovan(at)gmail(dot)com>
> wrote:
> > bt_page_items() returns two rows:
>
> > This does not make much sense to me to be honest...
>
> It doesn't look like UTF-8, but FWIW "31 39 36 38" is 1968 in ASCII
> (and every other encoding supported by Postgres). That's probably the
> first part of the string in each case.
>
> What do you mean about encoding conversion? It is rather unlikely that
> a bad client application would be able to do this kind of damage. If
> you're using UTF-8 as your database encoding, then Postgres tends to
> reject malformed strings when validated on input. Even if a malformed
> string is accepted into the database, it is only malformed to your
> application -- that shouldn't cause this kind of index corruption.
>
> --
> Peter Geoghegan
>