On 03/29/2016 07:43 PM, Peter Geoghegan wrote: > On Tue, Mar 29, 2016 at 7:31 PM, Tom Lane <t...@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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
