| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Vladimir Ryabtsev <greatvovan(at)gmail(dot)com> |
| Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: |
| Date: | 2019-09-25 01:48:02 |
| Message-ID: | CAH2-Wz=K1avLy4x4Rb_4y0O8pAkntk5w30UK1Ky-JDAdorqeuw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vladimir Ryabtsev | 2019-09-25 02:53:30 | Re: |
| Previous Message | Vladimir Ryabtsev | 2019-09-25 01:24:57 | Re: |