[COMMITTERS] pgsql: Add defenses against integer overflow in dynahash numbuckets cal

2012-12-11 Thread Tom Lane
Add defenses against integer overflow in dynahash numbuckets calculations. The dynahash code requires the number of buckets in a hash table to fit in an int; but since we calculate the desired hash table size dynamically, there are various scenarios where we might calculate too large a value. The

[COMMITTERS] pgsql: Add defenses against integer overflow in dynahash numbuckets cal

2012-12-11 Thread Tom Lane
Add defenses against integer overflow in dynahash numbuckets calculations. The dynahash code requires the number of buckets in a hash table to fit in an int; but since we calculate the desired hash table size dynamically, there are various scenarios where we might calculate too large a value. The

[COMMITTERS] pgsql: Add defenses against integer overflow in dynahash numbuckets cal

2012-12-11 Thread Tom Lane
Add defenses against integer overflow in dynahash numbuckets calculations. The dynahash code requires the number of buckets in a hash table to fit in an int; but since we calculate the desired hash table size dynamically, there are various scenarios where we might calculate too large a value. The

[COMMITTERS] pgsql: Add defenses against integer overflow in dynahash numbuckets cal

2012-12-11 Thread Tom Lane
Add defenses against integer overflow in dynahash numbuckets calculations. The dynahash code requires the number of buckets in a hash table to fit in an int; but since we calculate the desired hash table size dynamically, there are various scenarios where we might calculate too large a value. The

[COMMITTERS] pgsql: Add defenses against integer overflow in dynahash numbuckets cal

2012-12-11 Thread Tom Lane
Add defenses against integer overflow in dynahash numbuckets calculations. The dynahash code requires the number of buckets in a hash table to fit in an int; but since we calculate the desired hash table size dynamically, there are various scenarios where we might calculate too large a value. The

[COMMITTERS] pgsql: Add defenses against integer overflow in dynahash numbuckets cal

2012-12-11 Thread Tom Lane
Add defenses against integer overflow in dynahash numbuckets calculations. The dynahash code requires the number of buckets in a hash table to fit in an int; but since we calculate the desired hash table size dynamically, there are various scenarios where we might calculate too large a value. The

[COMMITTERS] pgsql: Disable event triggers in standalone mode.

2012-12-11 Thread Tom Lane
Disable event triggers in standalone mode. Per discussion, this seems necessary to allow recovery from broken event triggers, or broken indexes on pg_event_trigger. Dimitri Fontaine Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/cd3413ec3683918c9cb9cfb39ae5b2c32f23

[COMMITTERS] pgsql: Fix performance problems with autovacuum truncation in busy work

2012-12-11 Thread Kevin Grittner
Fix performance problems with autovacuum truncation in busy workloads. In situations where there are over 8MB of empty pages at the end of a table, the truncation work for trailing empty pages takes longer than deadlock_timeout, and there is frequent access to the table by processes other than aut

[COMMITTERS] pgsql: Fix pg_upgrade for invalid indexes

2012-12-11 Thread Bruce Momjian
Fix pg_upgrade for invalid indexes All versions of pg_upgrade upgraded invalid indexes caused by CREATE INDEX CONCURRENTLY failures and marked them as valid. The patch adds a check to all pg_upgrade versions and throws an error during upgrade or --check. Backpatch to 9.2, 9.1, 9.0. Patch slight

[COMMITTERS] pgsql: Fix pg_upgrade for invalid indexes

2012-12-11 Thread Bruce Momjian
Fix pg_upgrade for invalid indexes All versions of pg_upgrade upgraded invalid indexes caused by CREATE INDEX CONCURRENTLY failures and marked them as valid. The patch adds a check to all pg_upgrade versions and throws an error during upgrade or --check. Backpatch to 9.2, 9.1, 9.0. Patch slight

[COMMITTERS] pgsql: Fix pg_upgrade for invalid indexes

2012-12-11 Thread Bruce Momjian
Fix pg_upgrade for invalid indexes All versions of pg_upgrade upgraded invalid indexes caused by CREATE INDEX CONCURRENTLY failures and marked them as valid. The patch adds a check to all pg_upgrade versions and throws an error during upgrade or --check. Backpatch to 9.2, 9.1, 9.0. Patch slight

[COMMITTERS] pgsql: Fix pg_upgrade for invalid indexes

2012-12-11 Thread Bruce Momjian
Fix pg_upgrade for invalid indexes All versions of pg_upgrade upgraded invalid indexes caused by CREATE INDEX CONCURRENTLY failures and marked them as valid. The patch adds a check to all pg_upgrade versions and throws an error during upgrade or --check. Backpatch to 9.2, 9.1, 9.0. Patch slight

[COMMITTERS] pgsql: Consistency check should compare last record replayed, not last

2012-12-11 Thread Heikki Linnakangas
Consistency check should compare last record replayed, not last record read. EndRecPtr is the last record that we've read, but not necessarily yet replayed. CheckRecoveryConsistency should compare minRecoveryPoint with the last replayed record instead. This caused recovery to think it's reached co

[COMMITTERS] pgsql: Consistency check should compare last record replayed, not last

2012-12-11 Thread Heikki Linnakangas
Consistency check should compare last record replayed, not last record read. EndRecPtr is the last record that we've read, but not necessarily yet replayed. CheckRecoveryConsistency should compare minRecoveryPoint with the last replayed record instead. This caused recovery to think it's reached co

[COMMITTERS] pgsql: Consistency check should compare last record replayed, not last

2012-12-11 Thread Heikki Linnakangas
Consistency check should compare last record replayed, not last record read. EndRecPtr is the last record that we've read, but not necessarily yet replayed. CheckRecoveryConsistency should compare minRecoveryPoint with the last replayed record instead. This caused recovery to think it's reached co

[COMMITTERS] pgsql: Consistency check should compare last record replayed, not last

2012-12-11 Thread Heikki Linnakangas
Consistency check should compare last record replayed, not last record read. EndRecPtr is the last record that we've read, but not necessarily yet replayed. CheckRecoveryConsistency should compare minRecoveryPoint with the last replayed record instead. This caused recovery to think it's reached co

[COMMITTERS] pgsql: Add mode where contrib installcheck runs each module in a separa

2012-12-11 Thread Andrew Dunstan
Add mode where contrib installcheck runs each module in a separately named database. Normally each module is tested in a database named contrib_regression, which is dropped and recreated at the beginhning of each pg_regress run. This new mode, enabled by adding USE_MODULE_DB=1 to the make command

[COMMITTERS] pgsql: Add mode where contrib installcheck runs each module in a separa

2012-12-11 Thread Andrew Dunstan
Add mode where contrib installcheck runs each module in a separately named database. Normally each module is tested in a database named contrib_regression, which is dropped and recreated at the beginhning of each pg_regress run. This new mode, enabled by adding USE_MODULE_DB=1 to the make command

[COMMITTERS] pgsql: Add mode where contrib installcheck runs each module in a separa

2012-12-11 Thread Andrew Dunstan
Add mode where contrib installcheck runs each module in a separately named database. Normally each module is tested in a database named contrib_regression, which is dropped and recreated at the beginhning of each pg_regress run. This new mode, enabled by adding USE_MODULE_DB=1 to the make command

[COMMITTERS] pgsql: Add mode where contrib installcheck runs each module in a separa

2012-12-11 Thread Andrew Dunstan
Add mode where contrib installcheck runs each module in a separately named database. Normally each module is tested in a database named contrib_regression, which is dropped and recreated at the beginhning of each pg_regress run. This new mode, enabled by adding USE_MODULE_DB=1 to the make command