create index regression fail
Hi,
In current HEAD, create index regression is failing (at least here).
Is anyone else seeing this?
Attached regression.diffs
the query where the regression fails is:
SELECT count(*) FROM dupindexcols
WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX';
my first theory was that it was because some locale because mine is
es_EC.UTF-8 but the content of the table doesn't justify that,
my second theory was that it was because the index-only scan it's does
but turning off indexonly scan didn't give a different answer
this test case was added in commit
e2c2c2e8b1df7dfdb01e7e6f6191a569ce3c3195 to "Improve planner's
handling of duplicated index column expressions", so this commit broke
something or the count is wrong in the expected result
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Attachments:
regression.diffsapplication/octet-stream; name=regression.diffsDownload
*** /home/postgres/pgreleases/postgresql/src/test/regress/expected/create_index.out 2012-01-12 12:24:49.000000000 -0500
--- /home/postgres/pgreleases/postgresql/src/test/regress/results/create_index.out 2012-01-12 12:55:52.000000000 -0500
***************
*** 2480,2485 ****
WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX';
count
-------
! 500
(1 row)
--- 2480,2485 ----
WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX';
count
-------
! 502
(1 row)
======================================================================
Jaime Casanova <jaime@2ndquadrant.com> writes:
the query where the regression fails is:
SELECT count(*) FROM dupindexcols
WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX';
my first theory was that it was because some locale because mine is
es_EC.UTF-8 but the content of the table doesn't justify that,
[ experiments... ] Looks like you're wrong about that. In ec_EC locale
on my machine, the test accepts these rows that are not accepted in C
locale:
223 | LLKAAA
738 | LLEAAA
I'll change the lower bound to 'MA' and see if that's any more portable.
regards, tom lane
On Thu, Jan 12, 2012 at 1:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jaime Casanova <jaime@2ndquadrant.com> writes:
the query where the regression fails is:
SELECT count(*) FROM dupindexcols
WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX';my first theory was that it was because some locale because mine is
es_EC.UTF-8 but the content of the table doesn't justify that,[ experiments... ] Looks like you're wrong about that. In ec_EC locale
on my machine, the test accepts these rows that are not accepted in C
locale:223 | LLKAAA
738 | LLEAAA
oh! i remember now a thread where we talk about glibc not doing the
right thing about this:
http://archives.postgresql.org/message-id/20081215160148.GF4067@alvh.no-ip.org
an update to that post would be that in that time CH and LL where
independent letters but sorted as if they weren't, now they both were
degraded to be a combination of two letters.
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Excerpts from Jaime Casanova's message of jue ene 12 16:22:17 -0300 2012:
On Thu, Jan 12, 2012 at 1:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jaime Casanova <jaime@2ndquadrant.com> writes:
the query where the regression fails is:
SELECT count(*) FROM dupindexcols
WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX';my first theory was that it was because some locale because mine is
es_EC.UTF-8 but the content of the table doesn't justify that,[ experiments... ] Looks like you're wrong about that. In ec_EC locale
on my machine, the test accepts these rows that are not accepted in C
locale:223 | LLKAAA
738 | LLEAAAoh! i remember now a thread where we talk about glibc not doing the
right thing about this:
http://archives.postgresql.org/message-id/20081215160148.GF4067@alvh.no-ip.organ update to that post would be that in that time CH and LL where
independent letters but sorted as if they weren't, now they both were
degraded to be a combination of two letters.
Yeah, some of these are pretty recent developments by the "real academia
de la lengua", I guess glibc hasn't gotten word about it 100% yet. On
the other hand I wonder if es_EC is different from other spanish locales
for some reason ...
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support