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@bowt.ie>:
On Tue, Sep 24, 2019 at 6:25 PM Vladimir Ryabtsev <greatvovan@gmail.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.
