On 03/29/2016 07:43 PM, Peter Geoghegan wrote:
> On Tue, Mar 29, 2016 at 7:31 PM, Tom Lane <tgl@sss.pgh.pa.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.
I meant failing to detect a violation, and thus letting the user insert
a duplicate key.
> 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.
There was speculation on this in the -bugs thread, and nobody
contradicted it. If you're fairly sure that it wouldn't happen, your
knowledge of the issue is definitely superior to mine.
> 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.
I think that's a great idea.
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)