[COMMITTERS] bizgres - bizgres: Tagged version string.
Log Message: --- Tagged version string. Modified Files: -- bizgres/postgresql: configure (r1.1.1.3.2.1 -> r1.3) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/configure.diff?r1=1.1.1.3.2.1&r2=1.3) configure.in (r1.1.1.3.2.1 -> r1.3) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/configure.in.diff?r1=1.1.1.3.2.1&r2=1.3) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[COMMITTERS] bizgres - bizgres: Includes: 1.
Log Message: --- Includes: 1. Resolution of the copy issues on table that alerady has bitmap index. 2. Query run is fine for Bitmap And. Jie Modified Files: -- bizgres/postgresql/src/backend/access/bitmap: Makefile (r1.1 -> r1.2) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/backend/access/bitmap/Makefile.diff?r1=1.1&r2=1.2) bitmap.c (r1.2 -> r1.3) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/backend/access/bitmap/bitmap.c.diff?r1=1.2&r2=1.3) bitmapattutil.c (r1.2 -> r1.3) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/backend/access/bitmap/bitmapattutil.c.diff?r1=1.2&r2=1.3) bitmapcompare.c (r1.1 -> r1.2) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/backend/access/bitmap/bitmapcompare.c.diff?r1=1.1&r2=1.2) bitmapinsert.c (r1.2 -> r1.3) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/backend/access/bitmap/bitmapinsert.c.diff?r1=1.2&r2=1.3) bitmappages.c (r1.2 -> r1.3) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/backend/access/bitmap/bitmappages.c.diff?r1=1.2&r2=1.3) bitmapsearch.c (r1.2 -> r1.3) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/backend/access/bitmap/bitmapsearch.c.diff?r1=1.2&r2=1.3) bitmaputil.c (r1.2 -> r1.3) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/backend/access/bitmap/bitmaputil.c.diff?r1=1.2&r2=1.3) bitmapxlog.c (r1.2 -> r1.3) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/backend/access/bitmap/bitmapxlog.c.diff?r1=1.2&r2=1.3) bizgres/postgresql/src/backend/nodes: ondiskbitmapwords.c (r1.1 -> r1.2) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/backend/nodes/ondiskbitmapwords.c.diff?r1=1.1&r2=1.2) bizgres/postgresql/src/include/access: bitmap.h (r1.2 -> r1.3) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/include/access/bitmap.h.diff?r1=1.2&r2=1.3) bizgres/postgresql/src/include/nodes: ondiskbitmapwords.h (r1.1 -> r1.2) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/include/nodes/ondiskbitmapwords.h.diff?r1=1.1&r2=1.2) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[COMMITTERS] pgsql: Comments in IndexBuildHeapScan describe the indexing of
Log Message: --- Comments in IndexBuildHeapScan describe the indexing of recently-dead tuples as needed "to keep VACUUM from complaining", but actually there is a more compelling reason to do it: failure to do so violates MVCC semantics. This is because a pre-existing serializable transaction might try to use the index after we finish (re)building it, and it might fail to find tuples it should be able to see. We got this mostly right, but not in the case of partial indexes: the code mistakenly discarded recently-dead tuples for partial indexes. Fix that, and adjust the comments. Modified Files: -- pgsql/src/backend/catalog: index.c (r1.263 -> r1.264) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/index.c.diff?r1=1.263&r2=1.264) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[COMMITTERS] pgsql: Comments in IndexBuildHeapScan describe the indexing of
Log Message: --- Comments in IndexBuildHeapScan describe the indexing of recently-dead tuples as needed "to keep VACUUM from complaining", but actually there is a more compelling reason to do it: failure to do so violates MVCC semantics. This is because a pre-existing serializable transaction might try to use the index after we finish (re)building it, and it might fail to find tuples it should be able to see. We got this mostly right, but not in the case of partial indexes: the code mistakenly discarded recently-dead tuples for partial indexes. Fix that, and adjust the comments. Tags: REL8_1_STABLE Modified Files: -- pgsql/src/backend/catalog: index.c (r1.261.2.1 -> r1.261.2.2) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/index.c.diff?r1=1.261.2.1&r2=1.261.2.2) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[COMMITTERS] bizgres - bizgres: Introduce release Release-0_9_0
Log Message: --- Introduce release Release-0_9_0 Modified Files: -- bizgres: release.txt (r1.17 -> r1.18) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/release.txt.diff?r1=1.17&r2=1.18) ---(end of broadcast)--- TIP 6: explain analyze is your friend
