Re: [PERFORM] [OT] Very strange postgresql behaviour
In response to Arnau [EMAIL PROTECTED]: I have postgresql 7.4.2 running on debian and I have the oddest postgresql behaviour I've ever seen. I do the following queries: espsm_asme=# select customer_app_config_id, customer_app_config_name from customer_app_config where customer_app_config_id = 5929 or customer_app_config_id = 11527 order by customer_app_config_id; customer_app_config_id | customer_app_config_name +-- 5929 | INFO (1 row) I do the same query but changing the order of the or conditions: espsm_asme=# select customer_app_config_id, customer_app_config_name from customer_app_config where customer_app_config_id = 11527 or customer_app_config_id = 5929 order by customer_app_config_id; customer_app_config_id | customer_app_config_name +-- 11527 | MOVIDOSERENA TONI 5523 (1 row) As you can see, the configuration 5929 and 11527 both exists, but when I do the queries they don't appear. [snip] Just a guess, but perhaps your index is damaged. Have you tried REINDEXing? -- Bill Moran Collaborative Fusion Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] [OT] Very strange postgresql behaviour
Arnau wrote: Hi all, I have postgresql 7.4.2 running on debian and I have the oddest postgresql behaviour I've ever seen. You should upgrade. The latest 7.2 release is 7.4.15 I do the following queries: ... At first glance this looks like a bug in PostgreSQL, but.. Rules: A lot of rules that I don't paste as matter of length. Is there any SELECT rules by chance that might explain this? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] [OT] Very strange postgresql behaviour
Hi Bill, In response to Arnau [EMAIL PROTECTED]: I have postgresql 7.4.2 running on debian and I have the oddest postgresql behaviour I've ever seen. I do the following queries: espsm_asme=# select customer_app_config_id, customer_app_config_name from customer_app_config where customer_app_config_id = 5929 or customer_app_config_id = 11527 order by customer_app_config_id; customer_app_config_id | customer_app_config_name +-- 5929 | INFO (1 row) I do the same query but changing the order of the or conditions: espsm_asme=# select customer_app_config_id, customer_app_config_name from customer_app_config where customer_app_config_id = 11527 or customer_app_config_id = 5929 order by customer_app_config_id; customer_app_config_id | customer_app_config_name +-- 11527 | MOVIDOSERENA TONI 5523 (1 row) As you can see, the configuration 5929 and 11527 both exists, but when I do the queries they don't appear. [snip] Just a guess, but perhaps your index is damaged. Have you tried REINDEXing? Yes, I have tried with: reindex table customer_app_config reindex index pk_cag_customer_application_id but nothing changed. I also tried to drop the index: espsm_asme=# begin; drop index pk_cag_customer_application_id; BEGIN ERROR: cannot drop index pk_cag_customer_application_id because constraint pk_cag_customer_application_id on table customer_app_config requires it HINT: You may drop constraint pk_cag_customer_application_id on table customer_app_config instead. espsm_asme=# rollback; ROLLBACK But I can't remove the constraint as it's the primary key and there are foreign keys over it -- Arnau ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] [OT] Very strange postgresql behaviour
Arnau wrote: Hi Bill, In response to Arnau [EMAIL PROTECTED]: I have postgresql 7.4.2 running on debian and I have the oddest postgresql behaviour I've ever seen. I do the following queries: espsm_asme=# select customer_app_config_id, customer_app_config_name from customer_app_config where customer_app_config_id = 5929 or customer_app_config_id = 11527 order by customer_app_config_id; Just wild guessing: is there any chance that there may be some form of implicit limit modifier for the select statements on this table? Does the behaviour change if you add limit 2 at the end of the query? Does it change if you use customer_app_config_id in (5929, 11527) instead? Another wild guess: if the data is somewhat corrupt, maybe a vacuum analyze would detect it? Or perhaps try pg_dumping, to see if pg_dump at some point complains about mssing or corrupt data? HTH, Carlos -- ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
