[COMMITTERS] pgsql: Fix wording of logical decoding concepts

2016-09-03 Thread Simon Riggs
Fix wording of logical decoding concepts

Be specific about conditions under which we emit >1 copy of message

Craig Ringer

Branch
--
master

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

Modified Files
--
doc/src/sgml/logicaldecoding.sgml | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)


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


[COMMITTERS] pgsql: Fix wording of logical decoding concepts

2016-09-03 Thread Simon Riggs
Fix wording of logical decoding concepts

Be specific about conditions under which we emit >1 copy of message

Craig Ringer

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/33befe035d86d833a5bc7289612722a4e650227d

Modified Files
--
doc/src/sgml/logicaldecoding.sgml | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)


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


[COMMITTERS] pgsql: New recovery target recovery_target_lsn

2016-09-03 Thread Simon Riggs
New recovery target recovery_target_lsn

Michael Paquier

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/35250b6ad7a8ece5cfe54c0316c180df19f36c13

Modified Files
--
doc/src/sgml/recovery-config.sgml   | 24 +++--
src/backend/access/transam/recovery.conf.sample |  6 ++-
src/backend/access/transam/xlog.c   | 70 +
src/include/access/xlog.h   |  1 +
src/test/recovery/t/003_recovery_targets.pl | 28 --
5 files changed, 120 insertions(+), 9 deletions(-)


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


[COMMITTERS] pgsql: Fix corrupt GIN_SEGMENT_ADDITEMS WAL records on big-endian hardw

2016-09-03 Thread Tom Lane
Fix corrupt GIN_SEGMENT_ADDITEMS WAL records on big-endian hardware.

computeLeafRecompressWALData() tried to produce a uint16 WAL log field by
memcpy'ing the first two bytes of an int-sized variable.  That accidentally
works on little-endian hardware, but not at all on big-endian.  Replay then
thinks it's looking at an ADDITEMS action with zero entries, and reads the
first two bytes of the first TID therein as the next segno/action,
typically leading to "unexpected GIN leaf action" errors during replay.
Even if replay failed to crash, the resulting GIN index page would surely
be incorrect.  To fix, just declare the variable as uint16 instead.

Per bug #14295 from Spencer Thomason (much thanks to Spencer for turning
his problem into a self-contained test case).  This likely also explains
a previous report of the same symptom from Bernd Helmle.

Back-patch to 9.4 where the problem was introduced (by commit 14d02f0bb).

Discussion: <[email protected]>
Possible-Report: <[email protected]>

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/36646d3aff0cf6ff9f26033e38808d23e27426e8

Modified Files
--
src/backend/access/gin/gindatapage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


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


[COMMITTERS] pgsql: Fix corrupt GIN_SEGMENT_ADDITEMS WAL records on big-endian hardw

2016-09-03 Thread Tom Lane
Fix corrupt GIN_SEGMENT_ADDITEMS WAL records on big-endian hardware.

computeLeafRecompressWALData() tried to produce a uint16 WAL log field by
memcpy'ing the first two bytes of an int-sized variable.  That accidentally
works on little-endian hardware, but not at all on big-endian.  Replay then
thinks it's looking at an ADDITEMS action with zero entries, and reads the
first two bytes of the first TID therein as the next segno/action,
typically leading to "unexpected GIN leaf action" errors during replay.
Even if replay failed to crash, the resulting GIN index page would surely
be incorrect.  To fix, just declare the variable as uint16 instead.

Per bug #14295 from Spencer Thomason (much thanks to Spencer for turning
his problem into a self-contained test case).  This likely also explains
a previous report of the same symptom from Bernd Helmle.

Back-patch to 9.4 where the problem was introduced (by commit 14d02f0bb).

Discussion: <[email protected]>
Possible-Report: <[email protected]>

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/08a72872f516573c31f51868dbb82abd2b32f67a

Modified Files
--
src/backend/access/gin/gindatapage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


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


[COMMITTERS] pgsql: Fix corrupt GIN_SEGMENT_ADDITEMS WAL records on big-endian hardw

2016-09-03 Thread Tom Lane
Fix corrupt GIN_SEGMENT_ADDITEMS WAL records on big-endian hardware.

computeLeafRecompressWALData() tried to produce a uint16 WAL log field by
memcpy'ing the first two bytes of an int-sized variable.  That accidentally
works on little-endian hardware, but not at all on big-endian.  Replay then
thinks it's looking at an ADDITEMS action with zero entries, and reads the
first two bytes of the first TID therein as the next segno/action,
typically leading to "unexpected GIN leaf action" errors during replay.
Even if replay failed to crash, the resulting GIN index page would surely
be incorrect.  To fix, just declare the variable as uint16 instead.

Per bug #14295 from Spencer Thomason (much thanks to Spencer for turning
his problem into a self-contained test case).  This likely also explains
a previous report of the same symptom from Bernd Helmle.

Back-patch to 9.4 where the problem was introduced (by commit 14d02f0bb).

Discussion: <[email protected]>
Possible-Report: <[email protected]>

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/60893786d5180f5dd5aefd44d9cb6955d77b0473

Modified Files
--
src/backend/access/gin/gindatapage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


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


[COMMITTERS] pgsql: Fix corrupt GIN_SEGMENT_ADDITEMS WAL records on big-endian hardw

2016-09-03 Thread Tom Lane
Fix corrupt GIN_SEGMENT_ADDITEMS WAL records on big-endian hardware.

computeLeafRecompressWALData() tried to produce a uint16 WAL log field by
memcpy'ing the first two bytes of an int-sized variable.  That accidentally
works on little-endian hardware, but not at all on big-endian.  Replay then
thinks it's looking at an ADDITEMS action with zero entries, and reads the
first two bytes of the first TID therein as the next segno/action,
typically leading to "unexpected GIN leaf action" errors during replay.
Even if replay failed to crash, the resulting GIN index page would surely
be incorrect.  To fix, just declare the variable as uint16 instead.

Per bug #14295 from Spencer Thomason (much thanks to Spencer for turning
his problem into a self-contained test case).  This likely also explains
a previous report of the same symptom from Bernd Helmle.

Back-patch to 9.4 where the problem was introduced (by commit 14d02f0bb).

Discussion: <[email protected]>
Possible-Report: <[email protected]>

Branch
--
REL9_4_STABLE

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

Modified Files
--
src/backend/access/gin/gindatapage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


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


[COMMITTERS] pgsql: Fix multiple bugs in numeric_poly_deserialize().

2016-09-03 Thread Tom Lane
Fix multiple bugs in numeric_poly_deserialize().

These were evidently introduced by yesterday's commit 9cca11c91,
which perhaps needs more review than it got.

Per report from Andreas Seltenreich and additional examination
of nearby code.

Report: <[email protected]>

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/600dc4c0da3b8c094ccc1ae75b47c8320898c714

Modified Files
--
src/backend/utils/adt/numeric.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)


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


[COMMITTERS] pgsql: Improve readability of the output of psql's \timing command.

2016-09-03 Thread Tom Lane
Improve readability of the output of psql's \timing command.

In addition to the existing decimal-milliseconds output value,
display the same value in mm:ss.fff format if it exceeds one second.
Tack on hours and even days fields if the interval is large enough.
This avoids needing mental arithmetic to convert the values into
customary time units.

Corey Huinker, reviewed by Gerdan Santos; bikeshedding by many

Discussion: 

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/6591f4226c81104f7746da6a5c00519919c560ae

Modified Files
--
doc/src/sgml/ref/psql-ref.sgml |  7 --
src/bin/psql/common.c  | 56 --
2 files changed, 59 insertions(+), 4 deletions(-)


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