[COMMITTERS] pgsql: Unify spelling of canceled, canceling, cancellation

Unify spelling of canceled, canceling, cancellation We had previously (af26857a2775e7ceb0916155e931008c2116632f) established the U.S. spellings as standard. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/21f1e15aafb13ab2430e831a3da7d4d4f525d1ce Modified Files

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

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)

[COMMITTERS] stackbuilder - wizard: Improve error messages.

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.16r2=1.17) -- Sent via pgsql-committers mailing list

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

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-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers

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

Branch refs/heads/REL9_7_STABLE was removed. -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers

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

Just so people don't panic - this is me testing the policy script :-) //Magnus On Wed, Jun 29, 2011 at 16:31, pg...@postgresql.org 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

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

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-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers

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

Branch refs/heads/REL9_7_STABLE was removed. -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers

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

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

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: Move the PredicateLockRelation() call from nodeSeqscan.c to heap

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

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

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 --

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

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

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

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

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

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

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

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

[COMMITTERS] pgsql: Fix outdated comment

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