[COMMITTERS] pgsql: Fix buffer overflow on particularly named files and clarify docu

[Michael Meskes]

Fix buffer overflow on particularly named files and clarify documentation about
output file naming.

Patch by Tsunakawa, Takayuki 

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/501c9107487d33e234f4af8bf77f2aa64c05e6d3

Modified Files
--
doc/src/sgml/ref/ecpg-ref.sgml | 8 +++-
src/interfaces/ecpg/preproc/ecpg.c | 3 ++-
2 files changed, 5 insertions(+), 6 deletions(-)


-- 
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: Fix buffer overflow on particularly named files and clarify docu

[Michael Meskes]

Fix buffer overflow on particularly named files and clarify documentation about
output file naming.

Patch by Tsunakawa, Takayuki 

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/3af172f7b68763fbbf720d11be88784f21c4c1d1

Modified Files
--
doc/src/sgml/ref/ecpg-ref.sgml | 8 +++-
src/interfaces/ecpg/preproc/ecpg.c | 3 ++-
2 files changed, 5 insertions(+), 6 deletions(-)


-- 
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: Fix buffer overflow on particularly named files and clarify docu

[Michael Meskes]

Fix buffer overflow on particularly named files and clarify documentation about
output file naming.

Patch by Tsunakawa, Takayuki 

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/1df8b3fe820d4d589f6a38ea0d0c9e5714651509

Modified Files
--
doc/src/sgml/ref/ecpg-ref.sgml | 8 +++-
src/interfaces/ecpg/preproc/ecpg.c | 3 ++-
2 files changed, 5 insertions(+), 6 deletions(-)


-- 
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: Fix buffer overflow on particularly named files and clarify docu

[Michael Meskes]

Fix buffer overflow on particularly named files and clarify documentation about
output file naming.

Patch by Tsunakawa, Takayuki 

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/4032ef18d06aa7a3db515926ddebe8af04e533fe

Modified Files
--
doc/src/sgml/ref/ecpg-ref.sgml | 8 +++-
src/interfaces/ecpg/preproc/ecpg.c | 3 ++-
2 files changed, 5 insertions(+), 6 deletions(-)


-- 
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: Fix buffer overflow on particularly named files and clarify docu

[Michael Meskes]

Fix buffer overflow on particularly named files and clarify documentation about
output file naming.

Patch by Tsunakawa, Takayuki 

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/fd2a5547c523768b662cd2ea056080ad16c9f23f

Modified Files
--
doc/src/sgml/ref/ecpg-ref.sgml | 8 +++-
src/interfaces/ecpg/preproc/ecpg.c | 3 ++-
2 files changed, 5 insertions(+), 6 deletions(-)


-- 
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: Fix buffer overflow on particularly named files and clarify docu

[Michael Meskes]

Fix buffer overflow on particularly named files and clarify documentation about
output file naming.

Patch by Tsunakawa, Takayuki 

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/a88c547f926c1bd70d7dc180826e7e95824c88d1

Modified Files
--
doc/src/sgml/ref/ecpg-ref.sgml | 8 +++-
src/interfaces/ecpg/preproc/ecpg.c | 3 ++-
2 files changed, 5 insertions(+), 6 deletions(-)


-- 
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: Improve dblink error message when remote does not provide it

[Joe Conway]

Improve dblink error message when remote does not provide it

When dblink or postgres_fdw detects an error on the remote side of the
connection, it will try to construct a local error message as best it
can using libpq's PQresultErrorField(). When no primary message is
available, it was bailing out with an unhelpful "unknown error". Make
that message better and more style guide compliant. Per discussion
on hackers.

Backpatch to 9.2 except postgres_fdw which didn't exist before 9.3.

Discussion: https://postgr.es/m/19872.1482338965%40sss.pgh.pa.us

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/0f5b1867c2e6b752336f0b32d05f94c424664f79

Modified Files
--
contrib/dblink/dblink.c   | 2 +-
contrib/postgres_fdw/connection.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)


-- 
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: Improve dblink error message when remote does not provide it

[Joe Conway]

Improve dblink error message when remote does not provide it

When dblink or postgres_fdw detects an error on the remote side of the
connection, it will try to construct a local error message as best it
can using libpq's PQresultErrorField(). When no primary message is
available, it was bailing out with an unhelpful "unknown error". Make
that message better and more style guide compliant. Per discussion
on hackers.

Backpatch to 9.2 except postgres_fdw which didn't exist before 9.3.

Discussion: https://postgr.es/m/19872.1482338965%40sss.pgh.pa.us

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/88673c9d3bc72004367e3317175cb873584405bf

Modified Files
--
contrib/dblink/dblink.c   | 2 +-
contrib/postgres_fdw/connection.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)


-- 
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: Improve dblink error message when remote does not provide it

[Joe Conway]

Improve dblink error message when remote does not provide it

When dblink or postgres_fdw detects an error on the remote side of the
connection, it will try to construct a local error message as best it
can using libpq's PQresultErrorField(). When no primary message is
available, it was bailing out with an unhelpful "unknown error". Make
that message better and more style guide compliant. Per discussion
on hackers.

Backpatch to 9.2 except postgres_fdw which didn't exist before 9.3.

Discussion: https://postgr.es/m/19872.1482338965%40sss.pgh.pa.us

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/3272be3468956eedb9e18a5e1dc9eef352663152

Modified Files
--
contrib/dblink/dblink.c   | 2 +-
contrib/postgres_fdw/connection.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)


-- 
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: Improve dblink error message when remote does not provide it

[Joe Conway]

Improve dblink error message when remote does not provide it

When dblink or postgres_fdw detects an error on the remote side of the
connection, it will try to construct a local error message as best it
can using libpq's PQresultErrorField(). When no primary message is
available, it was bailing out with an unhelpful "unknown error". Make
that message better and more style guide compliant. Per discussion
on hackers.

Backpatch to 9.2 except postgres_fdw which didn't exist before 9.3.

Discussion: https://postgr.es/m/19872.1482338965%40sss.pgh.pa.us

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/28c9b6be7f76d64397bfa39a944915d4dbfd1994

Modified Files
--
contrib/dblink/dblink.c   | 2 +-
contrib/postgres_fdw/connection.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)


-- 
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: Improve dblink error message when remote does not provide it

[Joe Conway]

Improve dblink error message when remote does not provide it

When dblink or postgres_fdw detects an error on the remote side of the
connection, it will try to construct a local error message as best it
can using libpq's PQresultErrorField(). When no primary message is
available, it was bailing out with an unhelpful "unknown error". Make
that message better and more style guide compliant. Per discussion
on hackers.

Backpatch to 9.2 except postgres_fdw which didn't exist before 9.3.

Discussion: https://postgr.es/m/19872.1482338965%40sss.pgh.pa.us

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/ea0aa9698cfa74bb04cf53d813924fe67f278c30

Modified Files
--
contrib/dblink/dblink.c   | 2 +-
contrib/postgres_fdw/connection.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)


-- 
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: Improve dblink error message when remote does not provide it

[Joe Conway]

Improve dblink error message when remote does not provide it

When dblink or postgres_fdw detects an error on the remote side of the
connection, it will try to construct a local error message as best it
can using libpq's PQresultErrorField(). When no primary message is
available, it was bailing out with an unhelpful "unknown error". Make
that message better and more style guide compliant. Per discussion
on hackers.

Backpatch to 9.2 except postgres_fdw which didn't exist before 9.3.

Discussion: https://postgr.es/m/19872.1482338965%40sss.pgh.pa.us

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/fb0ab06dc4f4c90b85c220418445f4c8f15a59ca

Modified Files
--
contrib/dblink/dblink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
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: Fix detection of unfinished Unicode surrogate pair at end of str

[Tom Lane]

Fix detection of unfinished Unicode surrogate pair at end of string.

The U&'...' and U&"..." syntaxes silently discarded a surrogate pair
start (that is, a code between U+D800 and U+DBFF) if it occurred at
the very end of the string.  This seems like an obvious oversight,
since we throw an error for every other invalid combination of surrogate
characters, including the very same situation in E'...' syntax.

This has been wrong since the pair processing was added (in 9.0),
so back-patch to all supported branches.

Discussion: https://postgr.es/m/19113.1482337...@sss.pgh.pa.us

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/d0f60e4cc5f20bf64ee12d740e52db2773a93c21

Modified Files
--
src/backend/parser/scan.l | 8 
1 file changed, 8 insertions(+)


-- 
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: Fix detection of unfinished Unicode surrogate pair at end of str

[Tom Lane]

Fix detection of unfinished Unicode surrogate pair at end of string.

The U&'...' and U&"..." syntaxes silently discarded a surrogate pair
start (that is, a code between U+D800 and U+DBFF) if it occurred at
the very end of the string.  This seems like an obvious oversight,
since we throw an error for every other invalid combination of surrogate
characters, including the very same situation in E'...' syntax.

This has been wrong since the pair processing was added (in 9.0),
so back-patch to all supported branches.

Discussion: https://postgr.es/m/19113.1482337...@sss.pgh.pa.us

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/88e1e91da58422c5cf0e6e2d32f2aa15d75b8de9

Modified Files
--
src/backend/parser/scan.l | 7 +++
1 file changed, 7 insertions(+)


-- 
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: Fix detection of unfinished Unicode surrogate pair at end of str

[Tom Lane]

Fix detection of unfinished Unicode surrogate pair at end of string.

The U&'...' and U&"..." syntaxes silently discarded a surrogate pair
start (that is, a code between U+D800 and U+DBFF) if it occurred at
the very end of the string.  This seems like an obvious oversight,
since we throw an error for every other invalid combination of surrogate
characters, including the very same situation in E'...' syntax.

This has been wrong since the pair processing was added (in 9.0),
so back-patch to all supported branches.

Discussion: https://postgr.es/m/19113.1482337...@sss.pgh.pa.us

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/6e2c21ec5d1c2950c275818a4de6f98ac37da5de

Modified Files
--
src/backend/parser/scan.l | 8 
1 file changed, 8 insertions(+)


-- 
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: Fix detection of unfinished Unicode surrogate pair at end of str

[Tom Lane]

Fix detection of unfinished Unicode surrogate pair at end of string.

The U&'...' and U&"..." syntaxes silently discarded a surrogate pair
start (that is, a code between U+D800 and U+DBFF) if it occurred at
the very end of the string.  This seems like an obvious oversight,
since we throw an error for every other invalid combination of surrogate
characters, including the very same situation in E'...' syntax.

This has been wrong since the pair processing was added (in 9.0),
so back-patch to all supported branches.

Discussion: https://postgr.es/m/19113.1482337...@sss.pgh.pa.us

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/a57695d9a815ce355e17c5cdec181f87bc9de3f9

Modified Files
--
src/backend/parser/scan.l | 8 
1 file changed, 8 insertions(+)


-- 
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: Fix detection of unfinished Unicode surrogate pair at end of str

[Tom Lane]

Fix detection of unfinished Unicode surrogate pair at end of string.

The U&'...' and U&"..." syntaxes silently discarded a surrogate pair
start (that is, a code between U+D800 and U+DBFF) if it occurred at
the very end of the string.  This seems like an obvious oversight,
since we throw an error for every other invalid combination of surrogate
characters, including the very same situation in E'...' syntax.

This has been wrong since the pair processing was added (in 9.0),
so back-patch to all supported branches.

Discussion: https://postgr.es/m/19113.1482337...@sss.pgh.pa.us

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/a8ae12322ae056ebbe9d83cf16b4c92e86a6ac28

Modified Files
--
src/backend/parser/scan.l | 7 +++
1 file changed, 7 insertions(+)


-- 
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: Fix detection of unfinished Unicode surrogate pair at end of str

[Tom Lane]

Fix detection of unfinished Unicode surrogate pair at end of string.

The U&'...' and U&"..." syntaxes silently discarded a surrogate pair
start (that is, a code between U+D800 and U+DBFF) if it occurred at
the very end of the string.  This seems like an obvious oversight,
since we throw an error for every other invalid combination of surrogate
characters, including the very same situation in E'...' syntax.

This has been wrong since the pair processing was added (in 9.0),
so back-patch to all supported branches.

Discussion: https://postgr.es/m/19113.1482337...@sss.pgh.pa.us

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/d5633af7b60ba70fb0e1713df69af6672d52e2cd

Modified Files
--
src/backend/parser/scan.l | 8 
1 file changed, 8 insertions(+)


-- 
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: Fix base backup rate limiting in presence of slow i/o

[Magnus Hagander]

On Wed, Dec 21, 2016 at 6:55 PM, Dean Rasheed 
wrote:

> On 19 December 2016 at 09:17, Magnus Hagander  wrote:
> > Fix base backup rate limiting in presence of slow i/o
> >
> > Branch
> > --
> > REL9_4_STABLE
>
> I'm seeing a warning on the 9.4 branch that looks to have been caused
> by this commit:
>
> basebackup.c: In function ‘throttle’:
> basebackup.c:1284:8: warning: variable ‘wait_result’ set but not used
> [-Wunused-but-set-variable]
>   int   wait_result;
>

Interesting.

ff44fba4 replaced the latch in walsender, which was not backported (of
course).

But it also added a CHECK_FOR_INTERRUPTS there.

9.4 does not have a CHECK_FOR_INTERRUPTS anywhere near there. Perhaps
what's really needed is to put one of those in regardless?


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

[COMMITTERS] pgsql: Fix strange behavior (and possible crashes) in full text phrase

[Tom Lane]

Fix strange behavior (and possible crashes) in full text phrase search.

In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems.  The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich.  The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive.  And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.

As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.

To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.

This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.

Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.

Back-patch to 9.6 where phrase operators were introduced.  While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.

Discussion: https://postgr.es/m/28215.1481999...@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087...@sss.pgh.pa.us

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/4e2477b7b8b6c025d273a316852f2dbf62fff5bc

Modified Files
--
doc/src/sgml/datatype.sgml  |   8 -
doc/src/sgml/textsearch.sgml|  26 +-
src/backend/utils/adt/tsginidx.c|  28 +-
src/backend/utils/adt/tsgistidx.c   |  17 +-
src/backend/utils/adt/tsquery.c |  25 +-
src/backend/utils/adt/tsquery_cleanup.c | 242 +---
src/backend/utils/adt/tsquery_op.c  |   4 +-
src/backend/utils/adt/tsvector_op.c | 477 
src/include/tsearch/ts_utils.h  |  33 ++-
src/test/regress/expected/tsdicts.out   |  12 +-
src/test/regress/expected/tsearch.out   |  40 ++-
src/test/regress/expected/tstypes.out   | 298 ++--
src/test/regress/sql/tsearch.sql|   6 +
src/test/regress/sql/tstypes.sql|  56 ++--
14 files changed, 673 insertions(+), 599 deletions(-)


-- 
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: Fix strange behavior (and possible crashes) in full text phrase

[Tom Lane]

Fix strange behavior (and possible crashes) in full text phrase search.

In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems.  The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich.  The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive.  And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.

As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.

To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.

This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.

Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.

Back-patch to 9.6 where phrase operators were introduced.  While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.

Discussion: https://postgr.es/m/28215.1481999...@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087...@sss.pgh.pa.us

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/89fcea1ace40bc025beea2758a80bcd56a319a6f

Modified Files
--
doc/src/sgml/datatype.sgml  |   8 -
doc/src/sgml/textsearch.sgml|  26 +-
src/backend/utils/adt/tsginidx.c|  28 +-
src/backend/utils/adt/tsgistidx.c   |  17 +-
src/backend/utils/adt/tsquery.c |  25 +-
src/backend/utils/adt/tsquery_cleanup.c | 242 +---
src/backend/utils/adt/tsquery_op.c  |   4 +-
src/backend/utils/adt/tsvector_op.c | 477 
src/include/tsearch/ts_utils.h  |  31 ++-
src/test/regress/expected/tsdicts.out   |  12 +-
src/test/regress/expected/tsearch.out   |  40 ++-
src/test/regress/expected/tstypes.out   | 298 ++--
src/test/regress/sql/tsearch.sql|   6 +
src/test/regress/sql/tstypes.sql|  56 ++--
14 files changed, 671 insertions(+), 599 deletions(-)


-- 
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: Improve ALTER TABLE documentation

[Stephen Frost]

Improve ALTER TABLE documentation

The ALTER TABLE documentation wasn't terribly clear when it came to
which commands could be combined together and what it meant when they
were.

In particular, SET TABLESPACE *can* be combined with other commands,
when it's operating against a single table, but not when multiple tables
are being moved with ALL IN TABLESPACE.  Further, the actions are
applied together but not really in 'parallel', at least today.

Pointed out by: Amit Langote

Improved wording from Tom.

Back-patch to 9.4, where the ALL IN TABLESPACE option was added.

Discussion: 
https://www.postgresql.org/message-id/14c535b4-13ef-0590-1b98-76af355a0763%40lab.ntt.co.jp

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/2d1018ca56f5ddaf0bfb5b4d0133283f3e823301

Modified Files
--
doc/src/sgml/ref/alter_table.sgml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)


-- 
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: Improve ALTER TABLE documentation

[Stephen Frost]

Improve ALTER TABLE documentation

The ALTER TABLE documentation wasn't terribly clear when it came to
which commands could be combined together and what it meant when they
were.

In particular, SET TABLESPACE *can* be combined with other commands,
when it's operating against a single table, but not when multiple tables
are being moved with ALL IN TABLESPACE.  Further, the actions are
applied together but not really in 'parallel', at least today.

Pointed out by: Amit Langote

Improved wording from Tom.

Back-patch to 9.4, where the ALL IN TABLESPACE option was added.

Discussion: 
https://www.postgresql.org/message-id/14c535b4-13ef-0590-1b98-76af355a0763%40lab.ntt.co.jp

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/ec2bc3264ef007e6d7b6463029de689273161336

Modified Files
--
doc/src/sgml/ref/alter_table.sgml | 8 
1 file changed, 4 insertions(+), 4 deletions(-)


-- 
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: Improve ALTER TABLE documentation

[Stephen Frost]

Improve ALTER TABLE documentation

The ALTER TABLE documentation wasn't terribly clear when it came to
which commands could be combined together and what it meant when they
were.

In particular, SET TABLESPACE *can* be combined with other commands,
when it's operating against a single table, but not when multiple tables
are being moved with ALL IN TABLESPACE.  Further, the actions are
applied together but not really in 'parallel', at least today.

Pointed out by: Amit Langote

Improved wording from Tom.

Back-patch to 9.4, where the ALL IN TABLESPACE option was added.

Discussion: 
https://www.postgresql.org/message-id/14c535b4-13ef-0590-1b98-76af355a0763%40lab.ntt.co.jp

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/b5fe1d4cd93d281eef7ab6718716d169609b000a

Modified Files
--
doc/src/sgml/ref/alter_table.sgml | 8 
1 file changed, 4 insertions(+), 4 deletions(-)


-- 
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: Improve ALTER TABLE documentation

[Stephen Frost]

Improve ALTER TABLE documentation

The ALTER TABLE documentation wasn't terribly clear when it came to
which commands could be combined together and what it meant when they
were.

In particular, SET TABLESPACE *can* be combined with other commands,
when it's operating against a single table, but not when multiple tables
are being moved with ALL IN TABLESPACE.  Further, the actions are
applied together but not really in 'parallel', at least today.

Pointed out by: Amit Langote

Improved wording from Tom.

Back-patch to 9.4, where the ALL IN TABLESPACE option was added.

Discussion: 
https://www.postgresql.org/message-id/14c535b4-13ef-0590-1b98-76af355a0763%40lab.ntt.co.jp

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/eaac6c75858b693ef5e8968b509114c30896ba19

Modified Files
--
doc/src/sgml/ref/alter_table.sgml | 8 
1 file changed, 4 insertions(+), 4 deletions(-)


-- 
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: For 8.0 servers, get last built-in oid from pg_database

[Stephen Frost]

For 8.0 servers, get last built-in oid from pg_database

We didn't start ensuring that all built-in objects had OIDs less than
16384 until 8.1, so for 8.0 servers we still need to query the value out
of pg_database.  We need this, in particular, to distinguish which casts
were built-in and which were user-defined.

For HEAD, we only worry about going back to 8.0, for the back-branches,
we also ensure that 7.0-7.4 work.

Discussion: 
https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/107943f1a9b2823e5faef78f3ca1400a7612a24e

Modified Files
--
src/bin/pg_dump/pg_dump.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)


-- 
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: For 8.0 servers, get last built-in oid from pg_database

[Stephen Frost]

For 8.0 servers, get last built-in oid from pg_database

We didn't start ensuring that all built-in objects had OIDs less than
16384 until 8.1, so for 8.0 servers we still need to query the value out
of pg_database.  We need this, in particular, to distinguish which casts
were built-in and which were user-defined.

For HEAD, we only worry about going back to 8.0, for the back-branches,
we also ensure that 7.0-7.4 work.

Discussion: 
https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/e45319bb7796e3ab8095da329a1f73d22aaa57c4

Modified Files
--
src/bin/pg_dump/pg_dump.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)


-- 
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: Fix dumping of casts and transforms using built-in functions

[Stephen Frost]

Fix dumping of casts and transforms using built-in functions

In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the
cast or transform if it happened to use a built-in function because we
weren't including the information about built-in functions when querying
pg_proc from getFuncs().

Modify the query in getFuncs() to also gather information about
functions which are used by user-defined casts and transforms (where
"user-defined" means "has an OID >= FirstNormalObjectId").  This also
adds to the TAP regression tests for 9.6 and master to cover these
types of objects.

Back-patch all the way for casts, back to 9.5 for transforms.

Discussion: 
https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/da57166b7dceae917a73f414d9d13e07d4354066

Modified Files
--
src/bin/pg_dump/pg_dump.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)


-- 
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: For 8.0 servers, get last built-in oid from pg_database

[Stephen Frost]

For 8.0 servers, get last built-in oid from pg_database

We didn't start ensuring that all built-in objects had OIDs less than
16384 until 8.1, so for 8.0 servers we still need to query the value out
of pg_database.  We need this, in particular, to distinguish which casts
were built-in and which were user-defined.

For HEAD, we only worry about going back to 8.0, for the back-branches,
we also ensure that 7.0-7.4 work.

Discussion: 
https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/59a3898914d73fdf7bcac895098e7a164b64f4fe

Modified Files
--
src/bin/pg_dump/pg_dump.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)


-- 
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: For 8.0 servers, get last built-in oid from pg_database

[Stephen Frost]

For 8.0 servers, get last built-in oid from pg_database

We didn't start ensuring that all built-in objects had OIDs less than
16384 until 8.1, so for 8.0 servers we still need to query the value out
of pg_database.  We need this, in particular, to distinguish which casts
were built-in and which were user-defined.

For HEAD, we only worry about going back to 8.0, for the back-branches,
we also ensure that 7.0-7.4 work.

Discussion: 
https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/19990918d3fa2a445561627ed415b5891602f7fe

Modified Files
--
src/bin/pg_dump/pg_dump.c | 60 ++-
1 file changed, 54 insertions(+), 6 deletions(-)


-- 
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: Fix dumping of casts and transforms using built-in functions

[Stephen Frost]

Fix dumping of casts and transforms using built-in functions

In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the
cast or transform if it happened to use a built-in function because we
weren't including the information about built-in functions when querying
pg_proc from getFuncs().

Modify the query in getFuncs() to also gather information about
functions which are used by user-defined casts and transforms (where
"user-defined" means "has an OID >= FirstNormalObjectId").  This also
adds to the TAP regression tests for 9.6 and master to cover these
types of objects.

Back-patch all the way for casts, back to 9.5 for transforms.

Discussion: 
https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/542975a147525caa659ac08220b81c32a60f0a5c

Modified Files
--
src/bin/pg_dump/pg_dump.c| 46 +-
src/bin/pg_dump/t/002_pg_dump.pl | 82 +---
2 files changed, 88 insertions(+), 40 deletions(-)


-- 
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: Fix dumping of casts and transforms using built-in functions

[Stephen Frost]

Fix dumping of casts and transforms using built-in functions

In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the
cast or transform if it happened to use a built-in function because we
weren't including the information about built-in functions when querying
pg_proc from getFuncs().

Modify the query in getFuncs() to also gather information about
functions which are used by user-defined casts and transforms (where
"user-defined" means "has an OID >= FirstNormalObjectId").  This also
adds to the TAP regression tests for 9.6 and master to cover these
types of objects.

Back-patch all the way for casts, back to 9.5 for transforms.

Discussion: 
https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/13f51dacfab83f868df09370d10d4d9932fc0a61

Modified Files
--
src/bin/pg_dump/pg_dump.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)


-- 
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: For 8.0 servers, get last built-in oid from pg_database

[Stephen Frost]

For 8.0 servers, get last built-in oid from pg_database

We didn't start ensuring that all built-in objects had OIDs less than
16384 until 8.1, so for 8.0 servers we still need to query the value out
of pg_database.  We need this, in particular, to distinguish which casts
were built-in and which were user-defined.

For HEAD, we only worry about going back to 8.0, for the back-branches,
we also ensure that 7.0-7.4 work.

Discussion: 
https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/fc03f7dd195fba5ff3abd222d7e7d4a8e3a63341

Modified Files
--
src/bin/pg_dump/pg_dump.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)


-- 
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: Fix dumping of casts and transforms using built-in functions

[Stephen Frost]

Fix dumping of casts and transforms using built-in functions

In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the
cast or transform if it happened to use a built-in function because we
weren't including the information about built-in functions when querying
pg_proc from getFuncs().

Modify the query in getFuncs() to also gather information about
functions which are used by user-defined casts and transforms (where
"user-defined" means "has an OID >= FirstNormalObjectId").  This also
adds to the TAP regression tests for 9.6 and master to cover these
types of objects.

Back-patch all the way for casts, back to 9.5 for transforms.

Discussion: 
https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/2259bf672cb45b4104dcb835354beeb1c6105b0e

Modified Files
--
src/bin/pg_dump/pg_dump.c| 46 +-
src/bin/pg_dump/t/002_pg_dump.pl | 85 +---
2 files changed, 90 insertions(+), 41 deletions(-)


-- 
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: Fix dumping of casts and transforms using built-in functions

[Stephen Frost]

Fix dumping of casts and transforms using built-in functions

In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the
cast or transform if it happened to use a built-in function because we
weren't including the information about built-in functions when querying
pg_proc from getFuncs().

Modify the query in getFuncs() to also gather information about
functions which are used by user-defined casts and transforms (where
"user-defined" means "has an OID >= FirstNormalObjectId").  This also
adds to the TAP regression tests for 9.6 and master to cover these
types of objects.

Back-patch all the way for casts, back to 9.5 for transforms.

Discussion: 
https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/1efc5dba05a81bd91a0d3659f4a4ccfb4c36e680

Modified Files
--
src/bin/pg_dump/pg_dump.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)


-- 
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: For 8.0 servers, get last built-in oid from pg_database

[Stephen Frost]

For 8.0 servers, get last built-in oid from pg_database

We didn't start ensuring that all built-in objects had OIDs less than
16384 until 8.1, so for 8.0 servers we still need to query the value out
of pg_database.  We need this, in particular, to distinguish which casts
were built-in and which were user-defined.

For HEAD, we only worry about going back to 8.0, for the back-branches,
we also ensure that 7.0-7.4 work.

Discussion: 
https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/94476436a627d80319d49afe5724633b781e735a

Modified Files
--
src/bin/pg_dump/pg_dump.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)


-- 
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: Fix dumping of casts and transforms using built-in functions

[Stephen Frost]

Fix dumping of casts and transforms using built-in functions

In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the
cast or transform if it happened to use a built-in function because we
weren't including the information about built-in functions when querying
pg_proc from getFuncs().

Modify the query in getFuncs() to also gather information about
functions which are used by user-defined casts and transforms (where
"user-defined" means "has an OID >= FirstNormalObjectId").  This also
adds to the TAP regression tests for 9.6 and master to cover these
types of objects.

Back-patch all the way for casts, back to 9.5 for transforms.

Discussion: 
https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/1f2cfd26f50d3a7d885961aa68361d40d7753949

Modified Files
--
src/bin/pg_dump/pg_dump.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)


-- 
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: Fix base backup rate limiting in presence of slow i/o

[Dean Rasheed]

On 19 December 2016 at 09:17, Magnus Hagander  wrote:
> Fix base backup rate limiting in presence of slow i/o
>
> Branch
> --
> REL9_4_STABLE

I'm seeing a warning on the 9.4 branch that looks to have been caused
by this commit:

basebackup.c: In function ‘throttle’:
basebackup.c:1284:8: warning: variable ‘wait_result’ set but not used
[-Wunused-but-set-variable]
  int   wait_result;

Regards,
Dean


-- 
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: Fix order of operations in CREATE OR REPLACE VIEW.

[Dean Rasheed]

Fix order of operations in CREATE OR REPLACE VIEW.

When CREATE OR REPLACE VIEW acts on an existing view, don't update the
view options until after the view query has been updated.

This is necessary in the case where CREATE OR REPLACE VIEW is used on
an existing view that is not updatable, and the new view is updatable
and specifies the WITH CHECK OPTION. In this case, attempting to apply
the new options to the view before updating its query fails, because
the options are applied using the ALTER TABLE infrastructure which
checks that WITH CHECK OPTION is only applied to an updatable view.

If new columns are being added to the view, that is also done using
the ALTER TABLE infrastructure, but it is important that that still be
done before updating the view query, because the rules system checks
that the query columns match those on the view relation. Added a
comment to explain that, in case someone is tempted to move that to
where the view options are now being set.

Back-patch to 9.4 where WITH CHECK OPTION was added.

Report: 
https://postgr.es/m/CAEZATCUp%3Dz%3Ds4SzZjr14bfct_bdJNwMPi-gFi3Xc5k1ntbsAgQ%40mail.gmail.com

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/a46ee6b30ae9cba3ece5b4b5912969c74969f274

Modified Files
--
src/backend/commands/view.c   | 78 +--
src/test/regress/expected/updatable_views.out | 13 +
src/test/regress/sql/updatable_views.sql  | 14 +
3 files changed, 76 insertions(+), 29 deletions(-)


-- 
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: Fix order of operations in CREATE OR REPLACE VIEW.

[Dean Rasheed]

Fix order of operations in CREATE OR REPLACE VIEW.

When CREATE OR REPLACE VIEW acts on an existing view, don't update the
view options until after the view query has been updated.

This is necessary in the case where CREATE OR REPLACE VIEW is used on
an existing view that is not updatable, and the new view is updatable
and specifies the WITH CHECK OPTION. In this case, attempting to apply
the new options to the view before updating its query fails, because
the options are applied using the ALTER TABLE infrastructure which
checks that WITH CHECK OPTION is only applied to an updatable view.

If new columns are being added to the view, that is also done using
the ALTER TABLE infrastructure, but it is important that that still be
done before updating the view query, because the rules system checks
that the query columns match those on the view relation. Added a
comment to explain that, in case someone is tempted to move that to
where the view options are now being set.

Back-patch to 9.4 where WITH CHECK OPTION was added.

Report: 
https://postgr.es/m/CAEZATCUp%3Dz%3Ds4SzZjr14bfct_bdJNwMPi-gFi3Xc5k1ntbsAgQ%40mail.gmail.com

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/78a98b7674cf7d5d82001f6d8d4ebcb8344fc0cd

Modified Files
--
src/backend/commands/view.c   | 78 +--
src/test/regress/expected/updatable_views.out | 13 +
src/test/regress/sql/updatable_views.sql  | 14 +
3 files changed, 76 insertions(+), 29 deletions(-)


-- 
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: Fix order of operations in CREATE OR REPLACE VIEW.

[Dean Rasheed]

Fix order of operations in CREATE OR REPLACE VIEW.

When CREATE OR REPLACE VIEW acts on an existing view, don't update the
view options until after the view query has been updated.

This is necessary in the case where CREATE OR REPLACE VIEW is used on
an existing view that is not updatable, and the new view is updatable
and specifies the WITH CHECK OPTION. In this case, attempting to apply
the new options to the view before updating its query fails, because
the options are applied using the ALTER TABLE infrastructure which
checks that WITH CHECK OPTION is only applied to an updatable view.

If new columns are being added to the view, that is also done using
the ALTER TABLE infrastructure, but it is important that that still be
done before updating the view query, because the rules system checks
that the query columns match those on the view relation. Added a
comment to explain that, in case someone is tempted to move that to
where the view options are now being set.

Back-patch to 9.4 where WITH CHECK OPTION was added.

Report: 
https://postgr.es/m/CAEZATCUp%3Dz%3Ds4SzZjr14bfct_bdJNwMPi-gFi3Xc5k1ntbsAgQ%40mail.gmail.com

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/58b1362642d47bd7a7ed1157035a38671555e860

Modified Files
--
src/backend/commands/view.c   | 78 +--
src/test/regress/expected/updatable_views.out | 13 +
src/test/regress/sql/updatable_views.sql  | 14 +
3 files changed, 76 insertions(+), 29 deletions(-)


-- 
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: Fix order of operations in CREATE OR REPLACE VIEW.

[Dean Rasheed]

Fix order of operations in CREATE OR REPLACE VIEW.

When CREATE OR REPLACE VIEW acts on an existing view, don't update the
view options until after the view query has been updated.

This is necessary in the case where CREATE OR REPLACE VIEW is used on
an existing view that is not updatable, and the new view is updatable
and specifies the WITH CHECK OPTION. In this case, attempting to apply
the new options to the view before updating its query fails, because
the options are applied using the ALTER TABLE infrastructure which
checks that WITH CHECK OPTION is only applied to an updatable view.

If new columns are being added to the view, that is also done using
the ALTER TABLE infrastructure, but it is important that that still be
done before updating the view query, because the rules system checks
that the query columns match those on the view relation. Added a
comment to explain that, in case someone is tempted to move that to
where the view options are now being set.

Back-patch to 9.4 where WITH CHECK OPTION was added.

Report: 
https://postgr.es/m/CAEZATCUp%3Dz%3Ds4SzZjr14bfct_bdJNwMPi-gFi3Xc5k1ntbsAgQ%40mail.gmail.com

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/cad24980ef40a648fc72727ca14557968db29295

Modified Files
--
src/backend/commands/view.c   | 78 +--
src/test/regress/expected/updatable_views.out | 13 +
src/test/regress/sql/updatable_views.sql  | 14 +
3 files changed, 76 insertions(+), 29 deletions(-)


-- 
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: Convert elog() to ereport() and do some wordsmithing.

[Robert Haas]

Convert elog() to ereport() and do some wordsmithing.

It's not entirely clear that we should log a message here at all, but
it's certainly wrong to use elog() for a message that should clearly
be translatable.

Amit Langote

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/cd510f04137a1436ad6029da4998f5224395a08d

Modified Files
--
src/backend/commands/tablecmds.c  | 5 -
src/test/regress/expected/alter_table.out | 6 +++---
2 files changed, 7 insertions(+), 4 deletions(-)


-- 
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: Refactor partition tuple routing code to reduce duplication.

[Robert Haas]

Refactor partition tuple routing code to reduce duplication.

Amit Langote

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/1fc5c4945047e8e8c7aa1644b52dd0187b729181

Modified Files
--
src/backend/commands/copy.c| 72 ++
src/backend/executor/execMain.c| 92 ++
src/backend/executor/nodeModifyTable.c | 76 ++--
src/include/executor/executor.h|  5 ++
4 files changed, 127 insertions(+), 118 deletions(-)


-- 
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: Fix corner-case bug in WaitEventSetWaitBlock on Windows.

[Robert Haas]

Fix corner-case bug in WaitEventSetWaitBlock on Windows.

If we do not reset the FD_READ event, WaitForMultipleObjects won't
return it again again unless we've meanwhile read from the socket,
which is generally true but not guaranteed.  WaitEventSetWaitBlock
itself may fail to return the event to the caller if the latch is
also set, and even if we changed that, the caller isn't obliged to
handle all returned events at once.  On non-Windows systems, the
socket-read event is purely level-triggered, so this issue does
not exist.  To fix, make Windows reset the event when needed.

This bug was introduced by 98a64d0bd713cb89e61bef6432befc4b7b5da59e,
and causes hangs when trying to use the pldebugger extension.

Patch by Amit Kapial.  Reported and tested by Ashutosh Sharma, who
also provided some analysis.  Further analysis by Michael Paquier.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/3b790d256f8489d0765c3389d6860f1c6b4a9b2d

Modified Files
--
src/backend/storage/ipc/latch.c | 27 +++
src/include/storage/latch.h |  3 +++
2 files changed, 30 insertions(+)


-- 
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: Fix corner-case bug in WaitEventSetWaitBlock on Windows.

[Robert Haas]

Fix corner-case bug in WaitEventSetWaitBlock on Windows.

If we do not reset the FD_READ event, WaitForMultipleObjects won't
return it again again unless we've meanwhile read from the socket,
which is generally true but not guaranteed.  WaitEventSetWaitBlock
itself may fail to return the event to the caller if the latch is
also set, and even if we changed that, the caller isn't obliged to
handle all returned events at once.  On non-Windows systems, the
socket-read event is purely level-triggered, so this issue does
not exist.  To fix, make Windows reset the event when needed.

This bug was introduced by 98a64d0bd713cb89e61bef6432befc4b7b5da59e,
and causes hangs when trying to use the pldebugger extension.

Patch by Amit Kapial.  Reported and tested by Ashutosh Sharma, who
also provided some analysis.  Further analysis by Michael Paquier.

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/b98e5513f33154ede701963ee9115ea056e9dea9

Modified Files
--
src/backend/storage/ipc/latch.c | 27 +++
src/include/storage/latch.h |  3 +++
2 files changed, 30 insertions(+)


-- 
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: Refactor merge path generation code.

[Robert Haas]

Refactor merge path generation code.

This shouldn't change the set of paths that get generated in any
way, but it is preparatory work for further changes to allow a
partial path to be merge-joined witih a non-partial path to produce
a partial join path.

Dilip Kumar, with cosmetic adjustments by me.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/59649c3f1cbd536314c0060dcabd234deab148b2

Modified Files
--
src/backend/optimizer/path/joinpath.c | 461 ++
1 file changed, 250 insertions(+), 211 deletions(-)


-- 
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: Reorder pg_sequence columns to avoid alignment issue

[Peter Eisentraut]

Reorder pg_sequence columns to avoid alignment issue

On AIX, doubles are aligned at 4 bytes, but int64 is aligned at 8 bytes.
Our code assumes that doubles have alignment that can also be applied to
int64, but that fails in this case.  One effect is that
heap_form_tuple() writes tuples in a different layout than
Form_pg_sequence expects.

Rather than rewrite the whole alignment code, work around the issue by
reordering the columns in pg_sequence so that the first int64 column
naturally comes out at an 8-byte boundary.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/f3b421da5f4addc95812b9db05a24972b8fd9739

Modified Files
--
doc/src/sgml/catalogs.sgml| 14 +++---
src/backend/commands/sequence.c   |  4 ++--
src/include/catalog/catversion.h  |  2 +-
src/include/catalog/pg_sequence.h | 14 +++---
4 files changed, 17 insertions(+), 17 deletions(-)


-- 
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: Forbid invalid combination of options in pg_basebackup.

[Fujii Masao]

Forbid invalid combination of options in pg_basebackup.

Commit 56c7d8d4552180fd66fe48423bb2a9bb767c2d87 allowed pg_basebackup
to stream WAL in tar mode. But there is the restriction that WAL
streaming in tar mode works only when the value - (dash) is not
specified as output directory. This means that the combination of
three options "-D -", "-F t" and "-X stream" is invalid. However,
previously, even when those options were specified at the same time,
pg_basebackup background process unexpectedly started streaming WAL.
And then it exited with an error.

This commit changes pg_basebackup so that it errors out on such
invalid combination of options at the beginning.

Reviewed by Magnus Hagander, and patch by me.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/ecbdc4c555f43b1ac284c734752b00c2ea6f277b

Modified Files
--
src/bin/pg_basebackup/pg_basebackup.c | 10 ++
1 file changed, 10 insertions(+)


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