[COMMITTERS] pgsql: Improve error message on MSVC if perl*.lib is not found.

2016-09-23 Thread Heikki Linnakangas
Improve error message on MSVC if perl*.lib is not found. John Harvey, reviewed by Michael Paquier Discussion: Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/3c2d5d6600de388729c7d613962d524352b7a67f Modified Files -- src/tools/msvc/Mkvcbuild.pm | 5 +++

[COMMITTERS] pgsql: pg_ctl: Add promote wait option to help output

2016-09-23 Thread Peter Eisentraut
pg_ctl: Add promote wait option to help output pointed out by Masahiko Sawada Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/6fa51c79c7a645248a63205ce17af98ed404790d Modified Files -- src/bin/pg_ctl/pg_ctl.c | 6 +++--- 1 file changed, 3 insertions(+),

[COMMITTERS] pgsql: Avoid using PostmasterRandom() for DSM control segment ID.

2016-09-23 Thread Tom Lane
Avoid using PostmasterRandom() for DSM control segment ID. Commits 470d886c3 et al intended to fix the problem that the postmaster selected the same "random" DSM control segment ID on every start. But using PostmasterRandom() for that destroys the intended property that the delay between random_s

[COMMITTERS] pgsql: Avoid using PostmasterRandom() for DSM control segment ID.

2016-09-23 Thread Tom Lane
Avoid using PostmasterRandom() for DSM control segment ID. Commits 470d886c3 et al intended to fix the problem that the postmaster selected the same "random" DSM control segment ID on every start. But using PostmasterRandom() for that destroys the intended property that the delay between random_s

[COMMITTERS] pgsql: Avoid using PostmasterRandom() for DSM control segment ID.

2016-09-23 Thread Tom Lane
Avoid using PostmasterRandom() for DSM control segment ID. Commits 470d886c3 et al intended to fix the problem that the postmaster selected the same "random" DSM control segment ID on every start. But using PostmasterRandom() for that destroys the intended property that the delay between random_s

[COMMITTERS] pgsql: Avoid using PostmasterRandom() for DSM control segment ID.

2016-09-23 Thread Tom Lane
Avoid using PostmasterRandom() for DSM control segment ID. Commits 470d886c3 et al intended to fix the problem that the postmaster selected the same "random" DSM control segment ID on every start. But using PostmasterRandom() for that destroys the intended property that the delay between random_s

[COMMITTERS] pgsql: Don't trust CreateFileMapping() to clear the error code on succe

2016-09-23 Thread Tom Lane
Don't trust CreateFileMapping() to clear the error code on success. We must test GetLastError() even when CreateFileMapping() returns a non-null handle. If that value were left over from some previous system call, we might be fooled into thinking the segment already existed. Experimentation on Wi

[COMMITTERS] pgsql: Don't trust CreateFileMapping() to clear the error code on succe

2016-09-23 Thread Tom Lane
Don't trust CreateFileMapping() to clear the error code on success. We must test GetLastError() even when CreateFileMapping() returns a non-null handle. If that value were left over from some previous system call, we might be fooled into thinking the segment already existed. Experimentation on Wi

[COMMITTERS] pgsql: Don't trust CreateFileMapping() to clear the error code on succe

2016-09-23 Thread Tom Lane
Don't trust CreateFileMapping() to clear the error code on success. We must test GetLastError() even when CreateFileMapping() returns a non-null handle. If that value were left over from some previous system call, we might be fooled into thinking the segment already existed. Experimentation on Wi

[COMMITTERS] pgsql: Don't trust CreateFileMapping() to clear the error code on succe

2016-09-23 Thread Tom Lane
Don't trust CreateFileMapping() to clear the error code on success. We must test GetLastError() even when CreateFileMapping() returns a non-null handle. If that value were left over from some previous system call, we might be fooled into thinking the segment already existed. Experimentation on Wi

[COMMITTERS] pgsql: Remove useless code.

2016-09-23 Thread Tom Lane
Remove useless code. Apparent copy-and-pasteo in standby_desc_invalidations() had two entries for msg->id == SHAREDINVALRELMAP_ID. Aleksander Alekseev Discussion: <20160923090814.GB1238@e733> Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/959ea7fa76120449efa5d85ae

[COMMITTERS] pgsql: Remove useless code.

2016-09-23 Thread Tom Lane
Remove useless code. Apparent copy-and-pasteo in standby_desc_invalidations() had two entries for msg->id == SHAREDINVALRELMAP_ID. Aleksander Alekseev Discussion: <20160923090814.GB1238@e733> Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/a20435fe9aa52cd8c6

[COMMITTERS] pgsql: Fix incorrect logic for excluding range constructor functions in

2016-09-23 Thread Tom Lane
Fix incorrect logic for excluding range constructor functions in pg_dump. Faulty AND/OR nesting in the WHERE clause of getFuncs' SQL query led to dumping range constructor functions if they are part of an extension and we're in binary-upgrade mode. Actually, we don't want to dump them separately

[COMMITTERS] pgsql: Fix incorrect logic for excluding range constructor functions in

2016-09-23 Thread Tom Lane
Fix incorrect logic for excluding range constructor functions in pg_dump. Faulty AND/OR nesting in the WHERE clause of getFuncs' SQL query led to dumping range constructor functions if they are part of an extension and we're in binary-upgrade mode. Actually, we don't want to dump them separately

[COMMITTERS] pgsql: Fix incorrect logic for excluding range constructor functions in

2016-09-23 Thread Tom Lane
Fix incorrect logic for excluding range constructor functions in pg_dump. Faulty AND/OR nesting in the WHERE clause of getFuncs' SQL query led to dumping range constructor functions if they are part of an extension and we're in binary-upgrade mode. Actually, we don't want to dump them separately

[COMMITTERS] pgsql: Fix incorrect logic for excluding range constructor functions in

2016-09-23 Thread Tom Lane
Fix incorrect logic for excluding range constructor functions in pg_dump. Faulty AND/OR nesting in the WHERE clause of getFuncs' SQL query led to dumping range constructor functions if they are part of an extension and we're in binary-upgrade mode. Actually, we don't want to dump them separately

[COMMITTERS] pgsql: Fix incorrect logic for excluding range constructor functions in

2016-09-23 Thread Tom Lane
Fix incorrect logic for excluding range constructor functions in pg_dump. Faulty AND/OR nesting in the WHERE clause of getFuncs' SQL query led to dumping range constructor functions if they are part of an extension and we're in binary-upgrade mode. Actually, we don't want to dump them separately

[COMMITTERS] pgsql: Fix incorrect logic for excluding range constructor functions in

2016-09-23 Thread Tom Lane
Fix incorrect logic for excluding range constructor functions in pg_dump. Faulty AND/OR nesting in the WHERE clause of getFuncs' SQL query led to dumping range constructor functions if they are part of an extension and we're in binary-upgrade mode. Actually, we don't want to dump them separately

[COMMITTERS] pgsql: Doc: fix examples of # operators so they actually work.

2016-09-23 Thread Tom Lane
Doc: fix examples of # operators so they actually work. These worked as-is until around 7.0, but fail in newer versions because there are more operators named "#". Besides it's a bit inconsistent that only two of the examples on this page lack type names on their constants. Report: <201609230815

[COMMITTERS] pgsql: Doc: fix examples of # operators so they actually work.

2016-09-23 Thread Tom Lane
Doc: fix examples of # operators so they actually work. These worked as-is until around 7.0, but fail in newer versions because there are more operators named "#". Besides it's a bit inconsistent that only two of the examples on this page lack type names on their constants. Report: <201609230815

[COMMITTERS] pgsql: Doc: fix examples of # operators so they actually work.

2016-09-23 Thread Tom Lane
Doc: fix examples of # operators so they actually work. These worked as-is until around 7.0, but fail in newer versions because there are more operators named "#". Besides it's a bit inconsistent that only two of the examples on this page lack type names on their constants. Report: <201609230815

[COMMITTERS] pgsql: Doc: fix examples of # operators so they actually work.

2016-09-23 Thread Tom Lane
Doc: fix examples of # operators so they actually work. These worked as-is until around 7.0, but fail in newer versions because there are more operators named "#". Besides it's a bit inconsistent that only two of the examples on this page lack type names on their constants. Report: <201609230815

[COMMITTERS] pgsql: Doc: fix examples of # operators so they actually work.

2016-09-23 Thread Tom Lane
Doc: fix examples of # operators so they actually work. These worked as-is until around 7.0, but fail in newer versions because there are more operators named "#". Besides it's a bit inconsistent that only two of the examples on this page lack type names on their constants. Report: <201609230815

[COMMITTERS] pgsql: Doc: fix examples of # operators so they actually work.

2016-09-23 Thread Tom Lane
Doc: fix examples of # operators so they actually work. These worked as-is until around 7.0, but fail in newer versions because there are more operators named "#". Besides it's a bit inconsistent that only two of the examples on this page lack type names on their constants. Report: <201609230815

[COMMITTERS] pgsql: Doc: fix examples of # operators so they actually work.

2016-09-23 Thread Tom Lane
Doc: fix examples of # operators so they actually work. These worked as-is until around 7.0, but fail in newer versions because there are more operators named "#". Besides it's a bit inconsistent that only two of the examples on this page lack type names on their constants. Report: <201609230815

[COMMITTERS] pgsql: Install TAP test infrastructure so it's available for extension

2016-09-23 Thread Tom Lane
Install TAP test infrastructure so it's available for extension testing. When configured with --enable-tap-tests, "make install" will now install the Perl support files for TAP testing where PGXS will find them. This allows extensions to rely on $(prove_check) even when being built out-of-tree. B

[COMMITTERS] pgsql: Install TAP test infrastructure so it's available for extension

2016-09-23 Thread Tom Lane
Install TAP test infrastructure so it's available for extension testing. When configured with --enable-tap-tests, "make install" will now install the Perl support files for TAP testing where PGXS will find them. This allows extensions to rely on $(prove_check) even when being built out-of-tree. B

[COMMITTERS] pgsql: Install TAP test infrastructure so it's available for extension

2016-09-23 Thread Tom Lane
Install TAP test infrastructure so it's available for extension testing. When configured with --enable-tap-tests, "make install" will now install the Perl support files for TAP testing where PGXS will find them. This allows extensions to rely on $(prove_check) even when being built out-of-tree. B

[COMMITTERS] pgsql: Install TAP test infrastructure so it's available for extension

2016-09-23 Thread Tom Lane
Install TAP test infrastructure so it's available for extension testing. When configured with --enable-tap-tests, "make install" will now install the Perl support files for TAP testing where PGXS will find them. This allows extensions to rely on $(prove_check) even when being built out-of-tree. B

Re: [COMMITTERS] pgsql: Raise max setting of checkpoint_timeout to 1d

2016-09-23 Thread Andres Freund
On 2016-09-11 22:28:21 +, Simon Riggs wrote: > Raise max setting of checkpoint_timeout to 1d > > Previously checkpoint_timeout was capped at 3600s > New max setting is 86400s = 24h = 1d > > Discussion: [email protected] > > Branch > -- > REL9_6_STABLE FWIW, it's kind of sur

Re: [COMMITTERS] pgsql: Raise max setting of checkpoint_timeout to 1d

2016-09-23 Thread Tom Lane
Andres Freund writes: > FWIW, it's kind of surprising that this was backpatched. That means we > should include it in the current release notes. Yeah, I'll do a last round of release note updates sometime this weekend. regards, tom lane -- Sent via pgsql-committers mai