| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Josh berkus <josh(at)agliodbs(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Please correct/improve wiki page about abbreviated keys bug |
| Date: | 2016-03-30 02:43:46 |
| Message-ID: | CAM3SWZT4ab-7p5ZQE1VaZZpRuScS1umHFMisx9CeD2NsZ8whkA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 29, 2016 at 7:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> A corrupt index could easily fail to detect uniqueness violations (because
> searches fail to find entries they should find). Not sure I believe that
> it would make false reports of a uniqueness conflict that's not really
> there.
Sure. But looking at how texteq() is implemented, it certainly seems
impossible that that could happen. Must have been a miscommunication
somewhere. I'll fix it.
Do you think it would be okay if the SQL query to detect potentially
affected indexes only considered the leading attribute? Since that's
the only attribute that could use abbreviated keys, it ought to be
safe to not require users to REINDEX indexes that happen to have a
second-or-subsequent text/varchar(n) attribute that doesn't use the C
locale. Maybe it's not worth worrying about.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2016-03-30 02:53:53 | Re: Using quicksort for every external sort run |
| Previous Message | Tom Lane | 2016-03-30 02:40:46 | Re: pg_restore casts check constraints differently |