From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | christian_oederan(at)gmx(dot)de |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #6351: ERROR: btree index keys must be ordered by attribute |
Date: | 2011-12-22 16:27:15 |
Message-ID: | 15472.1324571235@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
christian_oederan(at)gmx(dot)de writes:
> our OR-Mapper accidently created an index that contained the same column
> twice, with the result that some SELECTs could not be executed anymore and
> gave the error message "btree index keys must be ordered by attribute".
> The problem can be reproduced with a new table every time:
> CREATE TABLE tab (id SERIAL, a INTEGER, b INTEGER);
> CREATE INDEX tab123 ON tab (a, b, a);
> SELECT a, b FROM tab WHERE a = 0 AND b = 0;
> ERROR: XX000: btree index keys must be ordered by attribute
Hmm. This didn't use to be allowed at all before 9.0; previous releases
would reject the index definition:
regression=# CREATE INDEX tab123 ON tab (a, b, a);
ERROR: duplicate key value violates unique constraint "pg_attribute_relid_attnam_index"
But now that we allow it it'd be nice if it actually worked :-(.
Looking into the archives I see that we were mainly thinking about
the possibility of exclusion constraints naming the same column
more than once, which may explain why nobody tried using such an
index for queries. I'll see about fixing this in HEAD, although
my initial guess is that it will be too invasive to back-patch.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira de Oliveira | 2011-12-22 17:22:46 | Re: BUG #6353: If there is invalid line in pg_hba.conf, DB start fails without any nofice and no logs in pgstartup. |
Previous Message | erkan | 2011-12-22 15:53:08 | BUG #6353: If there is invalid line in pg_hba.conf, DB start fails without any nofice and no logs in pgstartup. |