pgsql: Fix some errhint and errdetail strings missing a period

2018-12-06 Thread Michael Paquier
Fix some errhint and errdetail strings missing a period

As per the error message style guide of the documentation, those should
be full sentences.

Author: Daniel Gustafsson
Reviewed-by: Michael Paquier, Álvaro Herrera
Discussion: https://1e8d49b4-16bc-4420-b4ed-58501d9e0...@yesql.se

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/730422afcdb6784bbe20efc65de72156d470b0c4

Modified Files
--
contrib/amcheck/verify_nbtree.c|  2 +-
src/backend/commands/tablecmds.c   |  2 +-
src/backend/utils/adt/jsonfuncs.c  |  4 ++--
src/backend/utils/misc/guc.c   |  6 +++---
src/pl/plpgsql/src/pl_exec.c   |  2 +-
src/test/regress/expected/json.out |  6 +++---
src/test/regress/expected/jsonb.out|  6 +++---
src/test/regress/expected/plpgsql.out  | 16 
src/test/regress/expected/triggers.out |  2 +-
9 files changed, 23 insertions(+), 23 deletions(-)



pgsql: Improve our response to invalid format strings, and detect more

2018-12-06 Thread Tom Lane
Improve our response to invalid format strings, and detect more cases.

Places that are testing for *printf failure ought to include the format
string in their error reports, since bad-format-string is one of the
more likely causes of such failure.  This both makes it easier to find
and repair the mistake, and provides at least some useful info to the
user who stumbles across such a problem.

Also, tighten snprintf.c to report EINVAL for an invalid flag or
final character in a format %-spec (including the case where the
%-spec is missing a final character altogether).  This seems like
better project policy, and it also allows removing an instruction
or two from the hot code path.

Back-patch the error reporting change in pvsnprintf, since it should be
harmless and may be helpful; but not the snprintf.c change.

Per discussion of bug #15511 from Ertuğrul Kahveci, which reported an
invalid translated format string.  These changes don't fix that error,
but they should improve matters next time we make such a mistake.

Discussion: https://postgr.es/m/15511-1d8b6a0bc8741...@postgresql.org

Branch
--
REL9_6_STABLE

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

Modified Files
--
src/common/psprintf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Improve our response to invalid format strings, and detect more

2018-12-06 Thread Tom Lane
Improve our response to invalid format strings, and detect more cases.

Places that are testing for *printf failure ought to include the format
string in their error reports, since bad-format-string is one of the
more likely causes of such failure.  This both makes it easier to find
and repair the mistake, and provides at least some useful info to the
user who stumbles across such a problem.

Also, tighten snprintf.c to report EINVAL for an invalid flag or
final character in a format %-spec (including the case where the
%-spec is missing a final character altogether).  This seems like
better project policy, and it also allows removing an instruction
or two from the hot code path.

Back-patch the error reporting change in pvsnprintf, since it should be
harmless and may be helpful; but not the snprintf.c change.

Per discussion of bug #15511 from Ertuğrul Kahveci, which reported an
invalid translated format string.  These changes don't fix that error,
but they should improve matters next time we make such a mistake.

Discussion: https://postgr.es/m/15511-1d8b6a0bc8741...@postgresql.org

Branch
--
REL_11_STABLE

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

Modified Files
--
src/common/psprintf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Improve our response to invalid format strings, and detect more

2018-12-06 Thread Tom Lane
Improve our response to invalid format strings, and detect more cases.

Places that are testing for *printf failure ought to include the format
string in their error reports, since bad-format-string is one of the
more likely causes of such failure.  This both makes it easier to find
and repair the mistake, and provides at least some useful info to the
user who stumbles across such a problem.

Also, tighten snprintf.c to report EINVAL for an invalid flag or
final character in a format %-spec (including the case where the
%-spec is missing a final character altogether).  This seems like
better project policy, and it also allows removing an instruction
or two from the hot code path.

Back-patch the error reporting change in pvsnprintf, since it should be
harmless and may be helpful; but not the snprintf.c change.

Per discussion of bug #15511 from Ertuğrul Kahveci, which reported an
invalid translated format string.  These changes don't fix that error,
but they should improve matters next time we make such a mistake.

Discussion: https://postgr.es/m/15511-1d8b6a0bc8741...@postgresql.org

Branch
--
master

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

Modified Files
--
src/backend/utils/misc/guc.c |  4 ++--
src/common/psprintf.c|  4 ++--
src/port/snprintf.c  | 13 +
3 files changed, 13 insertions(+), 8 deletions(-)



pgsql: Improve our response to invalid format strings, and detect more

2018-12-06 Thread Tom Lane
Improve our response to invalid format strings, and detect more cases.

Places that are testing for *printf failure ought to include the format
string in their error reports, since bad-format-string is one of the
more likely causes of such failure.  This both makes it easier to find
and repair the mistake, and provides at least some useful info to the
user who stumbles across such a problem.

Also, tighten snprintf.c to report EINVAL for an invalid flag or
final character in a format %-spec (including the case where the
%-spec is missing a final character altogether).  This seems like
better project policy, and it also allows removing an instruction
or two from the hot code path.

Back-patch the error reporting change in pvsnprintf, since it should be
harmless and may be helpful; but not the snprintf.c change.

Per discussion of bug #15511 from Ertuğrul Kahveci, which reported an
invalid translated format string.  These changes don't fix that error,
but they should improve matters next time we make such a mistake.

Discussion: https://postgr.es/m/15511-1d8b6a0bc8741...@postgresql.org

Branch
--
REL9_5_STABLE

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

Modified Files
--
src/common/psprintf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Improve our response to invalid format strings, and detect more

2018-12-06 Thread Tom Lane
Improve our response to invalid format strings, and detect more cases.

Places that are testing for *printf failure ought to include the format
string in their error reports, since bad-format-string is one of the
more likely causes of such failure.  This both makes it easier to find
and repair the mistake, and provides at least some useful info to the
user who stumbles across such a problem.

Also, tighten snprintf.c to report EINVAL for an invalid flag or
final character in a format %-spec (including the case where the
%-spec is missing a final character altogether).  This seems like
better project policy, and it also allows removing an instruction
or two from the hot code path.

Back-patch the error reporting change in pvsnprintf, since it should be
harmless and may be helpful; but not the snprintf.c change.

Per discussion of bug #15511 from Ertuğrul Kahveci, which reported an
invalid translated format string.  These changes don't fix that error,
but they should improve matters next time we make such a mistake.

Discussion: https://postgr.es/m/15511-1d8b6a0bc8741...@postgresql.org

Branch
--
REL_10_STABLE

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

Modified Files
--
src/common/psprintf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Improve planner stats documentation

2018-12-06 Thread Stephen Frost
Improve planner stats documentation

It was pointed out that in the planner stats documentation under
Extended Statistics, one of the sentences was a bit awkward.  Improve
that by rewording it slightly.

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

Branch
--
REL_11_STABLE

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

Modified Files
--
doc/src/sgml/perform.sgml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Improve planner stats documentation

2018-12-06 Thread Stephen Frost
Improve planner stats documentation

It was pointed out that in the planner stats documentation under
Extended Statistics, one of the sentences was a bit awkward.  Improve
that by rewording it slightly.

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

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/7a55ccc477b58863f6c73c243c7adb79c9717eda

Modified Files
--
doc/src/sgml/perform.sgml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Improve planner stats documentation

2018-12-06 Thread Stephen Frost
Improve planner stats documentation

It was pointed out that in the planner stats documentation under
Extended Statistics, one of the sentences was a bit awkward.  Improve
that by rewording it slightly.

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

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/23f9e3e36b1b58625f79a741c0fa6468c682da4e

Modified Files
--
doc/src/sgml/perform.sgml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Cleanup minor pg_dump memory leaks

2018-12-06 Thread Stephen Frost
Cleanup minor pg_dump memory leaks

In dumputils, we may have successfully parsed the acls when we discover
that we can't parse the reverse ACLs and then return- check and free
aclitems if that happens.

In dumpTableSchema, move ftoptions and srvname under the relkind !=
RELKIND_VIEW branch (since they're only used there) and then check if
they've been allocated and, if so, free them at the end of that block.

Pointed out by Pavel Raiskup, though I didn't use those patches.

Discussion: https://postgr.es/m/2183976.vkcjmhd...@nb.usersys.redhat.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/369d494a4f5c1494a46adcf5c56f5462a83ef20d

Modified Files
--
src/bin/pg_dump/dumputils.c |  2 ++
src/bin/pg_dump/pg_dump.c   | 14 --
2 files changed, 10 insertions(+), 6 deletions(-)



pgsql: Cleanup comments in xlog compression

2018-12-06 Thread Stephen Frost
Cleanup comments in xlog compression

Skipping over the "hole" in full page images in the XLOG code was
described as being a form of compression, but this got a bit confusing
since we now have PGLZ-based compression happening, so adjust the
wording to discuss "removing" the "hole" and keeping the talk about
compression to where we're talking about using PGLZ-based compression of
the full page images.

Reviewed-By: Kyotaro Horiguchi
Discussion: https://postgr.es/m/20181127234341.gm3...@tamriel.snowman.net

Branch
--
master

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

Modified Files
--
src/backend/access/transam/xloginsert.c |  2 +-
src/include/access/xlogrecord.h | 15 +++
2 files changed, 8 insertions(+), 9 deletions(-)