[COMMITTERS] stackbuilder - wizard: Modified the Stackbuilder to raise a UAC in case

2011-06-29 Thread User Sachin
Log Message: --- Modified the Stackbuilder to raise a UAC in case non-administrative user launches the application Modified Files: -- wizard: CMakeLists.txt (r1.27 -> r1.28) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/stackbuilder/wizard/CMakeLists.txt?r1

[COMMITTERS] stackbuilder - wizard: Improve error messages.

2011-06-29 Thread Dave Page
Log Message: --- Improve error messages. Modified Files: -- wizard: StackBuilder.cpp (r1.16 -> r1.17) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/stackbuilder/wizard/StackBuilder.cpp?r1=1.16&r2=1.17) -- Sent via pgsql-committers mailing list (pgsql-commi

[COMMITTERS] pgsql: Branch refs/heads/REL9_7_STABLE was created

2011-06-29 Thread pgsql
Branch refs/heads/REL9_7_STABLE was created. View: http://git.postgresql.org/pg/shortlog/refs/heads/REL9_7_STABLE -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Branch refs/heads/REL9_7_STABLE was removed

2011-06-29 Thread pgsql
Branch refs/heads/REL9_7_STABLE was removed. -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Branch refs/heads/REL9_7_STABLE was created

2011-06-29 Thread Magnus Hagander
Just so people don't panic - this is me testing the policy script :-) //Magnus On Wed, Jun 29, 2011 at 16:31, wrote: > Branch refs/heads/REL9_7_STABLE was created. > > View: http://git.postgresql.org/pg/shortlog/refs/heads/REL9_7_STABLE > -- > Sent via pgsql-committers mailing list (pgsql-commi

[COMMITTERS] pgsql: Branch refs/heads/REL9_7_STABLE was created

2011-06-29 Thread pgsql
Branch refs/heads/REL9_7_STABLE was created. View: http://git.postgresql.org/pg/shortlog/refs/heads/REL9_7_STABLE -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Branch refs/heads/REL9_7_STABLE was removed

2011-06-29 Thread pgsql
Branch refs/heads/REL9_7_STABLE was removed. -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Protect pg_stat_reset_shared() against NULL input

2011-06-29 Thread Magnus Hagander
Protect pg_stat_reset_shared() against NULL input Per bug #6082, reported by Steve Haslam Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/3ec6e00ece5fc7483f8890306005f97a2c640861 Modified Files -- src/backend/utils/adt/pgstatfuncs.c | 14 +++

[COMMITTERS] pgsql: Protect pg_stat_reset_shared() against NULL input

2011-06-29 Thread Magnus Hagander
Protect pg_stat_reset_shared() against NULL input Per bug #6082, reported by Steve Haslam Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/cbfd82aad252fd86b560a7b7c3d87260a34a595e Modified Files -- src/backend/utils/adt/pgstatfuncs.c | 14 +++

[COMMITTERS] pgsql: Protect pg_stat_reset_shared() against NULL input

2011-06-29 Thread Magnus Hagander
Protect pg_stat_reset_shared() against NULL input Per bug #6082, reported by Steve Haslam Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/79aa44536f3980d324f486504cde643ce23bf5c6 Modified Files -- src/backend/utils/adt/pgstatfuncs.c | 14 +++---

[COMMITTERS] pgsql: Move the PredicateLockRelation() call from nodeSeqscan.c to heap

2011-06-29 Thread Heikki Linnakangas
Move the PredicateLockRelation() call from nodeSeqscan.c to heapam.c. It's more consistent that way, since all the other PredicateLock* calls are made in various heapam.c and index AM functions. The call in nodeSeqscan.c was unnecessarily aggressive anyway, there's no need to try to lock the relati

[COMMITTERS] pgsql: Grab predicate locks on matching tuples in a lossy bitmap heap s

2011-06-29 Thread Heikki Linnakangas
Grab predicate locks on matching tuples in a lossy bitmap heap scan. Non-lossy case was already handled correctly. Kevin Grittner Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/1aa447a1e1273e51f1bb34e085c021941db86212 Modified Files -- src/backen

[COMMITTERS] pgsql: Move the PredicateLockRelation() call from nodeSeqscan.c to heap

2011-06-29 Thread Heikki Linnakangas
Move the PredicateLockRelation() call from nodeSeqscan.c to heapam.c. It's more consistent that way, since all the other PredicateLock* calls are made in various heapam.c and index AM functions. The call in nodeSeqscan.c was unnecessarily aggressive anyway, there's no need to try to lock the relati

[COMMITTERS] pgsql: Grab predicate locks on matching tuples in a lossy bitmap heap s

2011-06-29 Thread Heikki Linnakangas
Grab predicate locks on matching tuples in a lossy bitmap heap scan. Non-lossy case was already handled correctly. Kevin Grittner Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/d9fe63acb033141be695815a8a663de8dae4f8af Modified Files -- src/backend/execu

[COMMITTERS] pgsql: Restore correct btree preprocessing of "indexedcol IS NULL" cond

2011-06-29 Thread Tom Lane
Restore correct btree preprocessing of "indexedcol IS NULL" conditions. Such a condition is unsatisfiable in combination with any other type of btree-indexable condition (since we assume btree operators are always strict). 8.3 and 8.4 had an explicit test for this, which I removed in commit 29c4a

[COMMITTERS] pgsql: Restore correct btree preprocessing of "indexedcol IS NULL" cond

2011-06-29 Thread Tom Lane
Restore correct btree preprocessing of "indexedcol IS NULL" conditions. Such a condition is unsatisfiable in combination with any other type of btree-indexable condition (since we assume btree operators are always strict). 8.3 and 8.4 had an explicit test for this, which I removed in commit 29c4a

[COMMITTERS] pgsql: Restore correct btree preprocessing of "indexedcol IS NULL" cond

2011-06-29 Thread Tom Lane
Restore correct btree preprocessing of "indexedcol IS NULL" conditions. Such a condition is unsatisfiable in combination with any other type of btree-indexable condition (since we assume btree operators are always strict). 8.3 and 8.4 had an explicit test for this, which I removed in commit 29c4a

[COMMITTERS] pgsql: Fix outdated comment

2011-06-29 Thread Alvaro Herrera
Fix outdated comment Extracted from a patch by Bernd Helmle Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/b36927fbe922d1aac5d6e42c04eecf65bf37f5f3 Modified Files -- src/backend/parser/parse_utilcmd.c |4 ++-- 1 files changed, 2 insertions(+), 2 dele