[COMMITTERS] pgsql: Fix behavior when converting a float infinity to numeric.

[Tom Lane]

Fix behavior when converting a float infinity to numeric.

float8_numeric() and float4_numeric() failed to consider the possibility
that the input is an IEEE infinity.  The results depended on the
platform-specific behavior of sprintf(): on most platforms you'd get
something like

ERROR:  invalid input syntax for type numeric: "inf"

but at least on Windows it's possible for the conversion to succeed and
deliver a finite value (typically 1), due to a nonstandard output format
from sprintf and lack of syntax error checking in these functions.

Since our numeric type lacks the concept of infinity, a suitable conversion
is impossible; the best thing to do is throw an explicit error before
letting sprintf do its thing.

While at it, let's use snprintf not sprintf.  Overrunning the buffer
should be impossible if sprintf does what it's supposed to, but this
is cheap insurance against a stack smash if it doesn't.

Problem reported by Taiki Kondo.  Patch by me based on fix suggestion
from KaiGai Kohei.  Back-patch to all supported branches.

Discussion: 
https://postgr.es/m/12a9442fbae80d4e8953883e0b84e088c8c...@bpxm01gp.gisp.nec.co.jp

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/07ea925e20ee80898638800c8479b48e7e97d431

Modified Files
--
src/backend/utils/adt/numeric.c   | 14 --
src/test/regress/expected/numeric.out | 21 +
src/test/regress/sql/numeric.sql  |  8 
3 files changed, 41 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: Fix behavior when converting a float infinity to numeric.

[Tom Lane]

Fix behavior when converting a float infinity to numeric.

float8_numeric() and float4_numeric() failed to consider the possibility
that the input is an IEEE infinity.  The results depended on the
platform-specific behavior of sprintf(): on most platforms you'd get
something like

ERROR:  invalid input syntax for type numeric: "inf"

but at least on Windows it's possible for the conversion to succeed and
deliver a finite value (typically 1), due to a nonstandard output format
from sprintf and lack of syntax error checking in these functions.

Since our numeric type lacks the concept of infinity, a suitable conversion
is impossible; the best thing to do is throw an explicit error before
letting sprintf do its thing.

While at it, let's use snprintf not sprintf.  Overrunning the buffer
should be impossible if sprintf does what it's supposed to, but this
is cheap insurance against a stack smash if it doesn't.

Problem reported by Taiki Kondo.  Patch by me based on fix suggestion
from KaiGai Kohei.  Back-patch to all supported branches.

Discussion: 
https://postgr.es/m/12a9442fbae80d4e8953883e0b84e088c8c...@bpxm01gp.gisp.nec.co.jp

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/def03e4bfe30c230d7532f2d7cfe5d7485a658a8

Modified Files
--
src/backend/utils/adt/numeric.c   | 14 --
src/test/regress/expected/numeric.out | 21 +
src/test/regress/sql/numeric.sql  |  8 
3 files changed, 41 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: Fix behavior when converting a float infinity to numeric.

[Tom Lane]

Fix behavior when converting a float infinity to numeric.

float8_numeric() and float4_numeric() failed to consider the possibility
that the input is an IEEE infinity.  The results depended on the
platform-specific behavior of sprintf(): on most platforms you'd get
something like

ERROR:  invalid input syntax for type numeric: "inf"

but at least on Windows it's possible for the conversion to succeed and
deliver a finite value (typically 1), due to a nonstandard output format
from sprintf and lack of syntax error checking in these functions.

Since our numeric type lacks the concept of infinity, a suitable conversion
is impossible; the best thing to do is throw an explicit error before
letting sprintf do its thing.

While at it, let's use snprintf not sprintf.  Overrunning the buffer
should be impossible if sprintf does what it's supposed to, but this
is cheap insurance against a stack smash if it doesn't.

Problem reported by Taiki Kondo.  Patch by me based on fix suggestion
from KaiGai Kohei.  Back-patch to all supported branches.

Discussion: 
https://postgr.es/m/12a9442fbae80d4e8953883e0b84e088c8c...@bpxm01gp.gisp.nec.co.jp

Branch
--
REL9_3_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/2e82fba0e6a9f5d3253b89e5f2de2b1bf042d71c

Modified Files
--
src/backend/utils/adt/numeric.c   | 14 --
src/test/regress/expected/numeric.out | 21 +
src/test/regress/sql/numeric.sql  |  8 
3 files changed, 41 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: Fix behavior when converting a float infinity to numeric.

[Tom Lane]

Fix behavior when converting a float infinity to numeric.

float8_numeric() and float4_numeric() failed to consider the possibility
that the input is an IEEE infinity.  The results depended on the
platform-specific behavior of sprintf(): on most platforms you'd get
something like

ERROR:  invalid input syntax for type numeric: "inf"

but at least on Windows it's possible for the conversion to succeed and
deliver a finite value (typically 1), due to a nonstandard output format
from sprintf and lack of syntax error checking in these functions.

Since our numeric type lacks the concept of infinity, a suitable conversion
is impossible; the best thing to do is throw an explicit error before
letting sprintf do its thing.

While at it, let's use snprintf not sprintf.  Overrunning the buffer
should be impossible if sprintf does what it's supposed to, but this
is cheap insurance against a stack smash if it doesn't.

Problem reported by Taiki Kondo.  Patch by me based on fix suggestion
from KaiGai Kohei.  Back-patch to all supported branches.

Discussion: 
https://postgr.es/m/12a9442fbae80d4e8953883e0b84e088c8c...@bpxm01gp.gisp.nec.co.jp

Branch
--
REL9_4_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/c38575edce0d75d4464af7b4153ba0cbf654fd9d

Modified Files
--
src/backend/utils/adt/numeric.c   | 14 --
src/test/regress/expected/numeric.out | 21 +
src/test/regress/sql/numeric.sql  |  8 
3 files changed, 41 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: Fix behavior when converting a float infinity to numeric.

[Tom Lane]

Fix behavior when converting a float infinity to numeric.

float8_numeric() and float4_numeric() failed to consider the possibility
that the input is an IEEE infinity.  The results depended on the
platform-specific behavior of sprintf(): on most platforms you'd get
something like

ERROR:  invalid input syntax for type numeric: "inf"

but at least on Windows it's possible for the conversion to succeed and
deliver a finite value (typically 1), due to a nonstandard output format
from sprintf and lack of syntax error checking in these functions.

Since our numeric type lacks the concept of infinity, a suitable conversion
is impossible; the best thing to do is throw an explicit error before
letting sprintf do its thing.

While at it, let's use snprintf not sprintf.  Overrunning the buffer
should be impossible if sprintf does what it's supposed to, but this
is cheap insurance against a stack smash if it doesn't.

Problem reported by Taiki Kondo.  Patch by me based on fix suggestion
from KaiGai Kohei.  Back-patch to all supported branches.

Discussion: 
https://postgr.es/m/12a9442fbae80d4e8953883e0b84e088c8c...@bpxm01gp.gisp.nec.co.jp

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/7769fc000aa3b959d3e1c7d7c3c2555aba7722c3

Modified Files
--
src/backend/utils/adt/numeric.c   | 14 --
src/test/regress/expected/numeric.out | 21 +
src/test/regress/sql/numeric.sql  |  8 
3 files changed, 41 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: Fix behavior when converting a float infinity to numeric.

[Tom Lane]

Fix behavior when converting a float infinity to numeric.

float8_numeric() and float4_numeric() failed to consider the possibility
that the input is an IEEE infinity.  The results depended on the
platform-specific behavior of sprintf(): on most platforms you'd get
something like

ERROR:  invalid input syntax for type numeric: "inf"

but at least on Windows it's possible for the conversion to succeed and
deliver a finite value (typically 1), due to a nonstandard output format
from sprintf and lack of syntax error checking in these functions.

Since our numeric type lacks the concept of infinity, a suitable conversion
is impossible; the best thing to do is throw an explicit error before
letting sprintf do its thing.

While at it, let's use snprintf not sprintf.  Overrunning the buffer
should be impossible if sprintf does what it's supposed to, but this
is cheap insurance against a stack smash if it doesn't.

Problem reported by Taiki Kondo.  Patch by me based on fix suggestion
from KaiGai Kohei.  Back-patch to all supported branches.

Discussion: 
https://postgr.es/m/12a9442fbae80d4e8953883e0b84e088c8c...@bpxm01gp.gisp.nec.co.jp

Branch
--
REL9_2_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/72d4fd08ea63e2855c0b54317a09047455ff8369

Modified Files
--
src/backend/utils/adt/numeric.c   | 14 --
src/test/regress/expected/numeric.out | 21 +
src/test/regress/sql/numeric.sql  |  8 
3 files changed, 41 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: Fix behavior when converting a float infinity to numeric.

[Tom Lane]

Fix behavior when converting a float infinity to numeric.

float8_numeric() and float4_numeric() failed to consider the possibility
that the input is an IEEE infinity.  The results depended on the
platform-specific behavior of sprintf(): on most platforms you'd get
something like

ERROR:  invalid input syntax for type numeric: "inf"

but at least on Windows it's possible for the conversion to succeed and
deliver a finite value (typically 1), due to a nonstandard output format
from sprintf and lack of syntax error checking in these functions.

Since our numeric type lacks the concept of infinity, a suitable conversion
is impossible; the best thing to do is throw an explicit error before
letting sprintf do its thing.

While at it, let's use snprintf not sprintf.  Overrunning the buffer
should be impossible if sprintf does what it's supposed to, but this
is cheap insurance against a stack smash if it doesn't.

Problem reported by Taiki Kondo.  Patch by me based on fix suggestion
from KaiGai Kohei.  Back-patch to all supported branches.

Discussion: 
https://postgr.es/m/12a9442fbae80d4e8953883e0b84e088c8c...@bpxm01gp.gisp.nec.co.jp

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/ad56dbd6c0b87e95fb1cf45025bb7dd8152a9f59

Modified Files
--
src/backend/utils/adt/numeric.c   | 14 --
src/test/regress/expected/numeric.out | 21 +
src/test/regress/sql/numeric.sql  |  8 
3 files changed, 41 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: Revert to 9.6 treatment of ALTER TYPE enumtype ADD VALUE.

[Tom Lane]

Revert to 9.6 treatment of ALTER TYPE enumtype ADD VALUE.

This reverts commit 15bc038f9, along with the followon commits 1635e80d3
and 984c92074 that tried to clean up the problems exposed by bug #14825.
The result was incomplete because it failed to address parallel-query
requirements.  With 10.0 release so close upon us, now does not seem like
the time to be adding more code to fix that.  I hope we can un-revert this
code and add the missing parallel query support during the v11 cycle.

Back-patch to v10.

Discussion: 
https://postgr.es/m/20170922185904.1448.16...@wrigleys.postgresql.org

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/93a1af0b3f63838774a9e524589344c3d44c867d

Modified Files
--
doc/src/sgml/ref/alter_type.sgml   |  5 +--
src/backend/access/transam/xact.c  |  4 --
src/backend/catalog/pg_enum.c  | 64 ---
src/backend/commands/typecmds.c| 29 ++--
src/backend/tcop/utility.c |  2 +-
src/backend/utils/adt/enum.c   | 90 --
src/backend/utils/errcodes.txt |  1 -
src/include/catalog/pg_enum.h  |  2 -
src/include/commands/typecmds.h|  2 +-
src/test/regress/expected/enum.out | 78 +
src/test/regress/sql/enum.sql  | 42 --
11 files changed, 49 insertions(+), 270 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: Revert to 9.6 treatment of ALTER TYPE enumtype ADD VALUE.

[Tom Lane]

Revert to 9.6 treatment of ALTER TYPE enumtype ADD VALUE.

This reverts commit 15bc038f9, along with the followon commits 1635e80d3
and 984c92074 that tried to clean up the problems exposed by bug #14825.
The result was incomplete because it failed to address parallel-query
requirements.  With 10.0 release so close upon us, now does not seem like
the time to be adding more code to fix that.  I hope we can un-revert this
code and add the missing parallel query support during the v11 cycle.

Back-patch to v10.

Discussion: 
https://postgr.es/m/20170922185904.1448.16...@wrigleys.postgresql.org

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/28e07270768518524291d7d7906668eb67f6b8a5

Modified Files
--
doc/src/sgml/ref/alter_type.sgml   |  5 +--
src/backend/access/transam/xact.c  |  4 --
src/backend/catalog/pg_enum.c  | 64 ---
src/backend/commands/typecmds.c| 29 ++--
src/backend/tcop/utility.c |  2 +-
src/backend/utils/adt/enum.c   | 90 --
src/backend/utils/errcodes.txt |  1 -
src/include/catalog/pg_enum.h  |  2 -
src/include/commands/typecmds.h|  2 +-
src/test/regress/expected/enum.out | 78 +
src/test/regress/sql/enum.sql  | 42 --
11 files changed, 49 insertions(+), 270 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: Improve vpath support in plperl build

[Peter Eisentraut]

On 9/27/17 15:14, Tom Lane wrote:
> Peter Eisentraut  writes:
>> Improve vpath support in plperl build
> 
> A fair chunk of the buildfarm doesn't like this.  It looks like
> xsubpp's "-output" option is a johnny-come-lately.

Yup, fixed that.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
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 plperl build

[Peter Eisentraut]

Fix plperl build

The changes in 639928c988c1c2f52bbe7ca89e8c7c78a041b3e2 turned out to
require Perl 5.9.3, which is newer than our minimum required version.
So revert back to the old code for the normal case and only use the new
variant when both coverage and vpath are used.  As the minimum Perl
version moves forward, we can drop the old code sometime.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/65c865620237bf1964757436a36c40af591d30fb

Modified Files
--
src/pl/plperl/GNUmakefile | 5 +
1 file changed, 5 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: Improve vpath support in plperl build

[Tom Lane]

Peter Eisentraut  writes:
> Improve vpath support in plperl build

A fair chunk of the buildfarm doesn't like this.  It looks like
xsubpp's "-output" option is a johnny-come-lately.

regards, tom lane


-- 
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 the CREATE POLICY documentation.

[Dean Rasheed]

Improve the CREATE POLICY documentation.

Provide a correct description of how multiple policies are combined,
clarify when SELECT permissions are required, mention SELECT FOR
UPDATE/SHARE, and do some other more minor tidying up.

Reviewed by Stephen Frost

Discussion: 
https://postgr.es/m/CAEZATCVrxyYbOFU8XbGHicz%2BmXPYzw%3DhfNL2XTphDt-53TomQQ%40mail.gmail.com

Back-patch to 9.5.

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/4d5d08c1cd52add02bdfadc00854135a3b6c88f6

Modified Files
--
doc/src/sgml/ref/create_policy.sgml | 206 +++-
1 file changed, 134 insertions(+), 72 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 the CREATE POLICY documentation.

[Dean Rasheed]

Improve the CREATE POLICY documentation.

Provide a correct description of how multiple policies are combined,
clarify when SELECT permissions are required, mention SELECT FOR
UPDATE/SHARE, and do some other more minor tidying up.

Reviewed by Stephen Frost

Discussion: 
https://postgr.es/m/CAEZATCVrxyYbOFU8XbGHicz%2BmXPYzw%3DhfNL2XTphDt-53TomQQ%40mail.gmail.com

Back-patch to 9.5.

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/6a21eb31b6deb0f76e8304fb9f12df272ed59f0c

Modified Files
--
doc/src/sgml/ref/create_policy.sgml | 170 +++-
1 file changed, 108 insertions(+), 62 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 the CREATE POLICY documentation.

[Dean Rasheed]

Improve the CREATE POLICY documentation.

Provide a correct description of how multiple policies are combined,
clarify when SELECT permissions are required, mention SELECT FOR
UPDATE/SHARE, and do some other more minor tidying up.

Reviewed by Stephen Frost

Discussion: 
https://postgr.es/m/CAEZATCVrxyYbOFU8XbGHicz%2BmXPYzw%3DhfNL2XTphDt-53TomQQ%40mail.gmail.com

Back-patch to 9.5.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/af44cbd5ecd7e1db0ae4bce75c8f1bce14b1d6db

Modified Files
--
doc/src/sgml/ref/create_policy.sgml | 206 +++-
1 file changed, 134 insertions(+), 72 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 the CREATE POLICY documentation.

[Dean Rasheed]

Improve the CREATE POLICY documentation.

Provide a correct description of how multiple policies are combined,
clarify when SELECT permissions are required, mention SELECT FOR
UPDATE/SHARE, and do some other more minor tidying up.

Reviewed by Stephen Frost

Discussion: 
https://postgr.es/m/CAEZATCVrxyYbOFU8XbGHicz%2BmXPYzw%3DhfNL2XTphDt-53TomQQ%40mail.gmail.com

Back-patch to 9.5.

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/af4bd075911d449ff1627188a4175d71d4e317d2

Modified Files
--
doc/src/sgml/ref/create_policy.sgml | 170 +++-
1 file changed, 108 insertions(+), 62 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 vpath support in plperl build

[Peter Eisentraut]

Improve vpath support in plperl build

Run xsubpp with the -output option instead of redirecting stdout.  That
ensures that the #line directives in the output file point to the right
place in a vpath build.  This in turn fixes an error in coverage builds
that it can't find the source files.

Refactor the makefile rules while we're here.

Reviewed-by: Michael Paquier 

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/639928c988c1c2f52bbe7ca89e8c7c78a041b3e2

Modified Files
--
src/pl/plperl/GNUmakefile | 8 ++--
1 file changed, 2 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: Get rid of parameterized marked sections in SGML

[Peter Eisentraut]

Get rid of parameterized marked sections in SGML

Previously, we created a variant of the installation instructions for
producing the plain-text INSTALL file by marking up certain parts of
installation.sgml using SGML parameterized marked sections.  Marked
sections will not work anymore in XML, so before we can convert the
documentation to XML, we need a new approach.

DocBook provides a "profiling" feature that allows selecting content
based on attributes, which would work here.  But it imposes a noticeable
overhead when building the full documentation and causes complications
when building some output formats, and given that we recently spent a
fair amount of effort optimizing the documentation build time, it seems
sad to have to accept that.

So as an alternative, (1) we create our own mini-profiling layer that
adjusts just the text we want, and (2) assemble the pieces of content
that we want in the INSTALL file using XInclude.  That way, there is no
overhead when building the full documentation and most of the "ugly"
stuff in installation.sgml can be removed and dealt with out of line.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/684cf76b83e9dc8aed12aeb9131d2208f61bd31f

Modified Files
--
doc/src/sgml/Makefile|   5 +-
doc/src/sgml/filelist.sgml   |   9 --
doc/src/sgml/installation.sgml   | 245 +--
doc/src/sgml/standalone-install.sgml |  28 
doc/src/sgml/standalone-install.xml  | 167 
doc/src/sgml/standalone-profile.xsl  |  81 
6 files changed, 280 insertions(+), 255 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: pg_basebackup: Add option to create replication slot

[Peter Eisentraut]

pg_basebackup: Add option to create replication slot

When requesting a particular replication slot, the new pg_basebackup
option -C/--create-slot creates it before starting to replicate from it.

Further refactor the slot creation logic to include the temporary slot
creation logic into the same function.  Add new arguments is_temporary
and preserve_wal to CreateReplicationSlot().  Print in --verbose mode
that a slot has been created.

Author: Michael Banck 

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/3709ca1cf069cee24ef8000cb6a479813b5537df

Modified Files
--
doc/src/sgml/ref/pg_basebackup.sgml  | 16 +++
src/bin/pg_basebackup/pg_basebackup.c| 63 
src/bin/pg_basebackup/pg_receivewal.c|  3 +-
src/bin/pg_basebackup/pg_recvlogical.c   |  4 +-
src/bin/pg_basebackup/receivelog.c   | 18 
src/bin/pg_basebackup/receivelog.h   |  1 -
src/bin/pg_basebackup/streamutil.c   | 16 ---
src/bin/pg_basebackup/streamutil.h   |  5 ++-
src/bin/pg_basebackup/t/010_pg_basebackup.pl | 27 +++-
9 files changed, 112 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