From: | Omar Kilani <omar(dot)kilani(at)gmail(dot)com> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Strangeness with UNIQUE indexes and UTF-8 |
Date: | 2021-06-06 16:38:29 |
Message-ID: | CA+8F9hgk+qv-YsiGiYgWF1MYTdNsbXy=UmbmzemDHki2BgE1Bg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hey Chap,
Yeah, I understand. Just ruling out the bad hardware scenario.
Plus the next person to Google this will hopefully stumble upon this
thread. :)
Regards,
Omar
On Sun, Jun 6, 2021 at 9:36 AM Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
> On 06/06/21 11:08, Omar Kilani wrote:
> > I'm running pg_verify_checksums on the cluster, but the database is
> > many TB so it'll be a bit.
>
> Index corruption because of a locale change would not be the sort of thing
> checksums would detect. Entries would be put into the index in the correct
> order according to the old collation. The same entries can be still there,
> intact, just fine according to the checksums, only the new collation would
> have put them in a different order. Index search algorithms that are fast,
> because they assume the entries to be correctly ordered, will skip regions
> of the index where the desired key "couldn't possibly be", and if that's
> where the old ordering put it, it won't be found.
>
> Regards,
> -Chap
>
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2021-06-06 17:26:22 | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic |
Previous Message | Tom Lane | 2021-06-06 16:38:26 | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |