[COMMITTERS] pgsql: Avoid palloc in critical section in GiST WAL-logging.

2014-04-03 Thread Heikki Linnakangas
Avoid palloc in critical section in GiST WAL-logging. Memory allocation can fail if you run out of memory, and inside a critical section that will lead to a PANIC. Use conservatively-sized arrays in stack instead. There was previously no explicit limit on the number of pages a GiST split can prod

[COMMITTERS] pgsql: Avoid palloc in critical section in GiST WAL-logging.

2014-04-03 Thread Heikki Linnakangas
Avoid palloc in critical section in GiST WAL-logging. Memory allocation can fail if you run out of memory, and inside a critical section that will lead to a PANIC. Use conservatively-sized arrays in stack instead. There was previously no explicit limit on the number of pages a GiST split can prod

[COMMITTERS] pgsql: Avoid palloc in critical section in GiST WAL-logging.

2014-04-03 Thread Heikki Linnakangas
Avoid palloc in critical section in GiST WAL-logging. Memory allocation can fail if you run out of memory, and inside a critical section that will lead to a PANIC. Use conservatively-sized arrays in stack instead. There was previously no explicit limit on the number of pages a GiST split can prod

[COMMITTERS] pgsql: Avoid palloc in critical section in GiST WAL-logging.

2014-04-03 Thread Heikki Linnakangas
Avoid palloc in critical section in GiST WAL-logging. Memory allocation can fail if you run out of memory, and inside a critical section that will lead to a PANIC. Use conservatively-sized arrays in stack instead. There was previously no explicit limit on the number of pages a GiST split can prod

[COMMITTERS] pgsql: Fix documentation about size of interval type.

2014-04-03 Thread Tom Lane
Fix documentation about size of interval type. It's been 16 bytes, not 12, for ages. This was fixed in passing in HEAD (commit 146604ec), but as a factual error it should have been back-patched. Per gripe from Tatsuhito Kasahara. Branch -- REL9_2_STABLE Details --- http://git.postgresql

[COMMITTERS] pgsql: Fix documentation about size of interval type.

2014-04-03 Thread Tom Lane
Fix documentation about size of interval type. It's been 16 bytes, not 12, for ages. This was fixed in passing in HEAD (commit 146604ec), but as a factual error it should have been back-patched. Per gripe from Tatsuhito Kasahara. Branch -- REL9_0_STABLE Details --- http://git.postgresql

[COMMITTERS] pgsql: Fix documentation about size of interval type.

2014-04-03 Thread Tom Lane
Fix documentation about size of interval type. It's been 16 bytes, not 12, for ages. This was fixed in passing in HEAD (commit 146604ec), but as a factual error it should have been back-patched. Per gripe from Tatsuhito Kasahara. Branch -- REL9_3_STABLE Details --- http://git.postgresql

[COMMITTERS] pgsql: Fix documentation about size of interval type.

2014-04-03 Thread Tom Lane
Fix documentation about size of interval type. It's been 16 bytes, not 12, for ages. This was fixed in passing in HEAD (commit 146604ec), but as a factual error it should have been back-patched. Per gripe from Tatsuhito Kasahara. Branch -- REL8_4_STABLE Details --- http://git.postgresql

[COMMITTERS] pgsql: Fix documentation about size of interval type.

2014-04-03 Thread Tom Lane
Fix documentation about size of interval type. It's been 16 bytes, not 12, for ages. This was fixed in passing in HEAD (commit 146604ec), but as a factual error it should have been back-patched. Per gripe from Tatsuhito Kasahara. Branch -- REL9_1_STABLE Details --- http://git.postgresql

[COMMITTERS] pgsql: Avoid promising that "ADD COLUMN ... DEFAULT NULL" is free.

2014-04-03 Thread Tom Lane
Avoid promising that "ADD COLUMN ... DEFAULT NULL" is free. The system realizes that DEFAULT NULL is dummy in simple cases, but not if a cast function (such as a length coercion) needs to be applied. It's dubious that suppressing that function call would be appropriate, anyway. For the moment, le

[COMMITTERS] pgsql: Fix documentation about joining pg_locks to other views.

2014-04-03 Thread Tom Lane
Fix documentation about joining pg_locks to other views. The advice to join to pg_prepared_xacts via the transaction column was not updated when the transaction column was replaced by virtualtransaction. Since it's not quite obvious how to do that join, give an explicit example. For consistency al

[COMMITTERS] pgsql: Fix documentation about joining pg_locks to other views.

2014-04-03 Thread Tom Lane
Fix documentation about joining pg_locks to other views. The advice to join to pg_prepared_xacts via the transaction column was not updated when the transaction column was replaced by virtualtransaction. Since it's not quite obvious how to do that join, give an explicit example. For consistency al

[COMMITTERS] pgsql: Fix documentation about joining pg_locks to other views.

2014-04-03 Thread Tom Lane
Fix documentation about joining pg_locks to other views. The advice to join to pg_prepared_xacts via the transaction column was not updated when the transaction column was replaced by virtualtransaction. Since it's not quite obvious how to do that join, give an explicit example. For consistency al

[COMMITTERS] pgsql: Fix documentation about joining pg_locks to other views.

2014-04-03 Thread Tom Lane
Fix documentation about joining pg_locks to other views. The advice to join to pg_prepared_xacts via the transaction column was not updated when the transaction column was replaced by virtualtransaction. Since it's not quite obvious how to do that join, give an explicit example. For consistency al

[COMMITTERS] pgsql: Fix documentation about joining pg_locks to other views.

2014-04-03 Thread Tom Lane
Fix documentation about joining pg_locks to other views. The advice to join to pg_prepared_xacts via the transaction column was not updated when the transaction column was replaced by virtualtransaction. Since it's not quite obvious how to do that join, give an explicit example. For consistency al

[COMMITTERS] pgsql: Fix documentation about joining pg_locks to other views.

2014-04-03 Thread Tom Lane
Fix documentation about joining pg_locks to other views. The advice to join to pg_prepared_xacts via the transaction column was not updated when the transaction column was replaced by virtualtransaction. Since it's not quite obvious how to do that join, give an explicit example. For consistency al

[COMMITTERS] pgsql: Code review for commit d26888bc4d1e539a82f21382b0000fe5bbf889d9.

2014-04-03 Thread Tom Lane
Code review for commit d26888bc4d1e539a82f21382bfe5bbf889d9. Mostly, copy-edit the comments; but also fix it to not reject domains over arrays. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/741364bf5caeeae79b83bbdba778805d286622ba Modified Files --

[COMMITTERS] pgsql: Fix non-equivalence of VARIADIC and non-VARIADIC function call f

2014-04-03 Thread Tom Lane
Fix non-equivalence of VARIADIC and non-VARIADIC function call formats. For variadic functions (other than VARIADIC ANY), the syntaxes foo(x,y,...) and foo(VARIADIC ARRAY[x,y,...]) should be considered equivalent, since the former is converted to the latter at parse time. They have indeed been eq

[COMMITTERS] pgsql: Fix non-equivalence of VARIADIC and non-VARIADIC function call f

2014-04-03 Thread Tom Lane
Fix non-equivalence of VARIADIC and non-VARIADIC function call formats. For variadic functions (other than VARIADIC ANY), the syntaxes foo(x,y,...) and foo(VARIADIC ARRAY[x,y,...]) should be considered equivalent, since the former is converted to the latter at parse time. They have indeed been eq