20 hours to find the fix Teodor, Kudos !
Nothing for the pride :(, my bug.
Due to the importance of the fix, will we see very soon a 8.3.5 ?
Don't known, see discussion. I think, that will make sense.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
20 hours to find the fix Teodor, Kudos !
Due to the importance of the fix, will we see very soon a 8.3.5 ?
Regards,
Laurent.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Fixed, patch attached.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
diff -c -r src.orig/backend/access/gist/gistget.c
src/backend/access/gist/gistget.c
*** src.orig/backend/access/gist/
Thank you, I reproduce the bug, will fix.
Sergey Konoplev wrote:
Ok, I've done the test case (see attachment).
8.3.3 has passed it.
8.3.4 hasn't passed in ~99% times I run it.
Steps to reproduce:
1. install pg 8.3.4, do initdb, start pg
2. correct PSQL parameter in pg-8.3.4_index_update_test.s
Ok, I've done the test case (see attachment).
8.3.3 has passed it.
8.3.4 hasn't passed in ~99% times I run it.
Steps to reproduce:
1. install pg 8.3.4, do initdb, start pg
2. correct PSQL parameter in pg-8.3.4_index_update_test.sh
3. run pg-8.3.4_index_update_test.sh few times
And you will see s
Ok, I've done the test case (see attachment).
8.3.3 has passed it.
8.3.4 hasn't passed in ~99% times I run it.
Steps to reproduce:
1. install pg 8.3.4, do initdb, start pg
2. correct PSQL parameter in pg-8.3.4_index_update_test.sh
3. run pg-8.3.4_index_update_test.sh few times
And you will see s
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> I still can't reproduce the bug, but found useless recheck condition with
> bitmap
> check:
> select 1 as st , 1::int4 as t into qq from generate_series(1,1) as t;
> create index qqidx on qq using gist (st) where t =1;
> INSERT INTO qq (SELECT (4 *
Hmm. So the problem seems to be statable as "a full-index scan on a
GIST index might fail to return all the rows, if the index has been
modified since creation". Teodor, can you think of anything you
changed recently in that area?
I still can't reproduce the bug, but found useless recheck cond
Hmm. So the problem seems to be statable as "a full-index scan on a
GIST index might fail to return all the rows, if the index has been
modified since creation". Teodor, can you think of anything you
changed recently in that area?
Only fixing possible duplicates during index scan. Will see.
-
> "Sergey Konoplev" <[EMAIL PROTECTED]> writes:
>> Will somebody explain what has happened and how to solve the problem please?
>
> Apparently you've found a bug in either btree_gist or the core GIST
> code. Can you put together a self-contained test case?
>
Ok, I will try.
One more thing I want
"Sergey Konoplev" <[EMAIL PROTECTED]> writes:
> db_online=> select obj_status_did, count(1) from person_online
> where obj_status_did = 1 group by obj_status_did;
> QUERY PLAN
> -
Sorry, I forget to paste explains
> explain showed that first query do index scan and second one sec scan.
>
db_online=> select obj_status_did, count(1) from person_online
where obj_status_did = 1 group by obj_status_did;
QUERY PLAN
"Sergey Konoplev" <[EMAIL PROTECTED]> writes:
> Will somebody explain what has happened and how to solve the problem please?
Apparently you've found a bug in either btree_gist or the core GIST
code. Can you put together a self-contained test case?
regards, tom lane
--
S
Hi all,
Well, we have migrated our server from 8.3.3 to 8.3.4. The server is
based on Red Hat and an instans it deals with insalled on RAMFS.
db_online=> select version();
version
PostgreSQL 8.3.4 on x86_64-
14 matches
Mail list logo
