From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Hannes Dorbath" <light(at)theendofthetunnel(dot)de>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Index trouble with 8.3b4 |
Date: | 2008-01-14 11:36:18 |
Message-ID: | 873at0hc5p.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Oooh ... I can't be sure that this is what's biting you, but I
> definitely see a bug that seems to match the symptoms. As the comments
> in index.c point out, CREATE INDEX CONCURRENTLY works like this:
>
> * validate_index() works by first gathering all the TIDs currently in the
> * index, using a bulkdelete callback that just stores the TIDs and doesn't
> * ever say "delete it". (This should be faster than a plain indexscan;
> * also, not all index AMs support full-index indexscan.) Then we sort the
> * TIDs, and finally scan the table doing a "merge join" against the TID list
> * to see which tuples are missing from the index.
>
> The scan is done using the regular heapscan code, which in 8.3 has been
> modified to enable "synchronized scanning", which means it might start
> from the middle of the table and wrap around.
Wow, I'm glad we caught this in beta. Thanks a lot to Hannes Dorbath for
testing and reporting it.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Schwarzer | 2008-01-14 12:36:03 | Re: Installation problem: failed to initialize lc_messages to "" |
Previous Message | Ashish Karalkar | 2008-01-14 11:08:54 | ERROR: shared buffer hash table corrupted |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Mielke | 2008-01-14 13:11:20 | Re: Postgresql Materialized views |
Previous Message | Hannes Dorbath | 2008-01-14 10:44:42 | Re: Index trouble with 8.3b4 |