Interesting new bug?

Allright, I'm running 7.0.2 with Tom Lane's backwards index scan patch
applied.

I'm attempting to select out of a large table (10GB) with about 4
million rows, and it winds up just sitting and doing "nothing" forever.
If I check the process list, I see it using about 9% of the CPU.

This table is vacuum analyzed nightly - here's a description and EXPLAIN
from the query I'm trying to run.

Any ideas? I haven't been able to run the admin pages on Geocrawler ever
since I upgraded to 7.0.2

Tim

db_geocrawler=# \d tbl_mail_archive
Table "tbl_mail_archive"
Attribute | Type |
Modifier
----------------------+----------+----------------------------------------------
fld_mailid | integer | not null default
nextval('seq_mailid'::text)
fld_mail_list | integer |
fld_mail_date | char(14) |
fld_mail_is_followup | integer |
fld_mail_from | text |
fld_mail_subject | text |
fld_mail_body | text |
fld_mail_email | text |
fld_mail_year | integer |
fld_mail_month | integer |
Indices: idx_archive_list,
idx_archive_list_date,
idx_archive_year,
idx_mail_archive_list_yr_mo,
tbl_mail_archive_pkey

I'm manually deleting the rows without knowing what they are - and
that's bad - this query shows that the rows do exist, but for some
reason you can't select them out of the db.

db_geocrawler=# begin;
BEGIN
db_geocrawler=# delete from tbl_mail_archive where fld_mail_list=0;
DELETE 1032
db_geocrawler=# delete from tbl_mail_chunks where fld_mail_list=0;
DELETE 39
db_geocrawler=# commit;
COMMIT

db_geocrawler=# explain SELECT * FROM tbl_mail_archive WHERE
fld_mail_list=0 ORDER BY fld_mailid ASC LIMIT 10 OFFSET 0;
NOTICE: QUERY PLAN:

Index Scan using tbl_mail_archive_pkey on tbl_mail_archive
(cost=0.00..6402391.68 rows=19357 width=80)

EXPLAIN

--
Founder - PHPBuilder.com / Geocrawler.com
Lead Developer - SourceForge
VA Linux Systems
408-542-5723