Oops, I guess it wasn't offlist. Anyway, now everyone knows I might
have been one of the original authors that required the triple-commit
fix. ;-)
---
On Sun, Oct 4, 2015 at 09:57:52PM -0400, Bruce Momjian wrote:
>
> Off
Offlist, I think it was this commit:
commit 73a7c322c36bb96d4e2d053ff245b0f7b99f09e0
Author: Bruce Momjian
Date: Sun Jul 10 03:46:13 2005 +
Add psql \pset numericsep to allow output numbers like 100,000.0 or
100.000,0.
ALTER TABLE .. FORCE ROW LEVEL SECURITY
To allow users to force RLS to always be applied, even for table owners,
add ALTER TABLE .. FORCE ROW LEVEL SECURITY.
row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump
output is complete (by default).
Also add SECURITY_NOFORCE_RLS cont
ALTER TABLE .. FORCE ROW LEVEL SECURITY
To allow users to force RLS to always be applied, even for table owners,
add ALTER TABLE .. FORCE ROW LEVEL SECURITY.
row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump
output is complete (by default).
Also add SECURITY_NOFORCE_RLS cont
Release notes for 9.5beta1, 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23.
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/04811c350b76b4bbccde1dea43c8032f7f8524df
Modified Files
--
doc/src/sgml/release-9.0.sgml | 475 +
doc
Release notes for 9.5beta1, 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/16a70e3059885739f59ccdaa20f2e4a3b2a0a700
Modified Files
--
doc/src/sgml/release-9.0.sgml | 475 +
doc/src/sg
Release notes for 9.5beta1, 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23.
Branch
--
REL9_0_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/3d8987fc211b4a271da032d3351e87cd8d122912
Modified Files
--
doc/src/sgml/release-9.0.sgml | 475 +
Release notes for 9.5beta1, 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23.
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/2be5a4438aa63f354b44ff9cb2feb394d90a71ac
Modified Files
--
doc/src/sgml/release-9.0.sgml | 475
Release notes for 9.5beta1, 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23.
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/e78dc6b829219cacaccc59957b5375585e919099
Modified Files
--
doc/src/sgml/release-9.0.sgml | 475 ++
doc/src/sgml/release-9
Release notes for 9.5beta1, 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23.
Branch
--
REL9_4_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/439b65e84e2464e1881e56e2f7218553730293dc
Modified Files
--
doc/src/sgml/release-9.0.sgml | 475 ++
doc/src/sgml/release-9
Release notes for 9.5beta1, 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23.
Branch
--
REL9_2_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/795d5e427f64232f50f8f52919556f346a9af694
Modified Files
--
doc/src/sgml/release-9.0.sgml | 475 ++
do
Improve contrib/pg_stat_statements' handling of garbage collection failure.
If we can't read the query texts file (whether because out-of-memory, or
for some other reason), give up and reset the file to empty, discarding all
stored query texts, though not the statistics per se. We used to leave
t
Improve contrib/pg_stat_statements' handling of garbage collection failure.
If we can't read the query texts file (whether because out-of-memory, or
for some other reason), give up and reset the file to empty, discarding all
stored query texts, though not the statistics per se. We used to leave
t
Improve contrib/pg_stat_statements' handling of garbage collection failure.
If we can't read the query texts file (whether because out-of-memory, or
for some other reason), give up and reset the file to empty, discarding all
stored query texts, though not the statistics per se. We used to leave
t
Fix hstore_plpython test when python3 is used.
Due to b67aaf21e8ef8 / CREATE EXTENSION ... CASCADE the test output
contains the extension name in yet another place. Since that's variable
depending on the python version...
Add yet another name mangling stanza to regress-python3-mangle.mk.
Author:
Further twiddling of nodeHash.c hashtable sizing calculation.
On reflection, the submitted patch didn't really work to prevent the
request size from exceeding MaxAllocSize, because of the fact that we'd
happily round nbuckets up to the next power of 2 after we'd limited it to
max_pointers. The si
Further twiddling of nodeHash.c hashtable sizing calculation.
On reflection, the submitted patch didn't really work to prevent the
request size from exceeding MaxAllocSize, because of the fact that we'd
happily round nbuckets up to the next power of 2 after we'd limited it to
max_pointers. The si
Further twiddling of nodeHash.c hashtable sizing calculation.
On reflection, the submitted patch didn't really work to prevent the
request size from exceeding MaxAllocSize, because of the fact that we'd
happily round nbuckets up to the next power of 2 after we'd limited it to
max_pointers. The si
Further twiddling of nodeHash.c hashtable sizing calculation.
On reflection, the submitted patch didn't really work to prevent the
request size from exceeding MaxAllocSize, because of the fact that we'd
happily round nbuckets up to the next power of 2 after we'd limited it to
max_pointers. The si
Further twiddling of nodeHash.c hashtable sizing calculation.
On reflection, the submitted patch didn't really work to prevent the
request size from exceeding MaxAllocSize, because of the fact that we'd
happily round nbuckets up to the next power of 2 after we'd limited it to
max_pointers. The si
Further twiddling of nodeHash.c hashtable sizing calculation.
On reflection, the submitted patch didn't really work to prevent the
request size from exceeding MaxAllocSize, because of the fact that we'd
happily round nbuckets up to the next power of 2 after we'd limited it to
max_pointers. The si
Further twiddling of nodeHash.c hashtable sizing calculation.
On reflection, the submitted patch didn't really work to prevent the
request size from exceeding MaxAllocSize, because of the fact that we'd
happily round nbuckets up to the next power of 2 after we'd limited it to
max_pointers. The si
Fix possible "invalid memory alloc request size" failure in nodeHash.c.
Limit the size of the hashtable pointer array to not more than
MaxAllocSize. We've seen reports of failures due to this in HEAD/9.5,
and it seems possible in older branches as well. The change in
NTUP_PER_BUCKET in 9.5 may h
Fix possible "invalid memory alloc request size" failure in nodeHash.c.
Limit the size of the hashtable pointer array to not more than
MaxAllocSize. We've seen reports of failures due to this in HEAD/9.5,
and it seems possible in older branches as well. The change in
NTUP_PER_BUCKET in 9.5 may h
Fix possible "invalid memory alloc request size" failure in nodeHash.c.
Limit the size of the hashtable pointer array to not more than
MaxAllocSize. We've seen reports of failures due to this in HEAD/9.5,
and it seems possible in older branches as well. The change in
NTUP_PER_BUCKET in 9.5 may h
Fix possible "invalid memory alloc request size" failure in nodeHash.c.
Limit the size of the hashtable pointer array to not more than
MaxAllocSize. We've seen reports of failures due to this in HEAD/9.5,
and it seems possible in older branches as well. The change in
NTUP_PER_BUCKET in 9.5 may h
Fix possible "invalid memory alloc request size" failure in nodeHash.c.
Limit the size of the hashtable pointer array to not more than
MaxAllocSize. We've seen reports of failures due to this in HEAD/9.5,
and it seems possible in older branches as well. The change in
NTUP_PER_BUCKET in 9.5 may h
Fix some issues in new hashtable size calculations in nodeHash.c.
Limit the size of the hashtable pointer array to not more than
MaxAllocSize, per reports from Kouhei Kaigai and others of "invalid memory
alloc request size" failures. There was discussion of allowing the array
to get larger than t
Fix some issues in new hashtable size calculations in nodeHash.c.
Limit the size of the hashtable pointer array to not more than
MaxAllocSize, per reports from Kouhei Kaigai and others of "invalid memory
alloc request size" failures. There was discussion of allowing the array
to get larger than t
Disallow invalid path elements in jsonb_set
Null path elements and, where the object is an array, invalid integer
elements now cause an error.
Incorrect behaviour noted by Thom Brown, patch from Dmitry Dolgov.
Backpatch to 9.5 where jsonb_set was introduced
Branch
--
REL9_5_STABLE
Details
Disallow invalid path elements in jsonb_set
Null path elements and, where the object is an array, invalid integer
elements now cause an error.
Incorrect behaviour noted by Thom Brown, patch from Dmitry Dolgov.
Backpatch to 9.5 where jsonb_set was introduced
Branch
--
master
Details
---
Group cluster_name and update_process_title settings together
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/e45f8f882055d5f864815aa29ffcd2b5e3c2013b
Modified Files
--
doc/src/sgml/config.sgml | 97 ++---
Group cluster_name and update_process_title settings together
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/6390c8c654d07c08686adbbc595a13d76b573653
Modified Files
--
doc/src/sgml/config.sgml | 97 ++---
src/bac
On October 4, 2015 12:55:46 PM GMT+02:00, Petr Jelinek
wrote:
>On 2015-10-04 05:47, Tom Lane wrote:
>> Andres Freund writes:
>>> Add CASCADE support for CREATE EXTENSION.
>>
>> Buildfarm results suggest this was not tested with python 3.
>>
>
>Attached patch fixes it on my machine.
Thanks. Will
On 2015-10-04 05:47, Tom Lane wrote:
Andres Freund writes:
Add CASCADE support for CREATE EXTENSION.
Buildfarm results suggest this was not tested with python 3.
Attached patch fixes it on my machine.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 2
35 matches
Mail list logo
