== PostgreSQL Weekly News - April 10 2016 ==

== PostgreSQL Weekly News - April 10 2016 ==

== PostgreSQL Product News ==

pgpool-II 3.5.1, 3.4.5, 3.3.9, 3.2.14, 3.1.17, and pgpoolAdmin 3.5.1
released.  pgpool-II is a connection pooler and replication system for
PostgreSQL.
http://pgpool.net/mediawiki/index.php/Downloads

psqlODBC 09.05.0200 released.
https://odbc.postgresql.org/docs/release.html

== PostgreSQL Jobs for April ==

http://archives.postgresql.org/pgsql-jobs/2016-04/

== PostgreSQL Local ==

PGConf US 2016 will take place April 18-20, 2016 in NYC.  Registration
is open.
http://www.pgconf.us/2016/

LinuxFest Northwest will take place April 23-24, 2016 at Bellingham
Technical College in Bellingham, Washington, USA.  The CfP is now
open.
http://www.linuxfestnorthwest.org/2016/present

FOSS4G NA, will be held May 2-5, 2016 in Raleigh, North Carolina.
The CfP is still open.
https://2016.foss4g-na.org/cfp

PGCon 2016 will be held May 17-21, 2016 in Ottawa.
http://www.pgcon.org/

This year's Swiss PGDay will be held on June 24, 2016 at the
University of Applied Sciences in Rapperswil (Switzerland).
The CfP is open.
http://www.pgday.ch/

"5432 ... Meet us!", will take place in Milan, Italy on June 28-29, 2016.
Registration is open.
http://5432meet.us/

PG Day UK 2016 will be 5th July 2016.
http://www.pgconf.uk/

PgConf Silicon Valley 2016 will be held on November 14-16, 2016.
http://www.pgconfsv.com/

== PostgreSQL in the News ==

Planet PostgreSQL: http://planet.postgresql.org/

PostgreSQL Weekly News is brought to you this week by David Fetter

Submit news and announcements by Sunday at 3:00pm Pacific time.
Please send English language ones to david@fetter.org, German language
to pwn@pgug.de, Italian language to pwn@itpug.org.  Spanish language
to pwn@arpug.com.ar.

== Applied Patches ==

Tom Lane pushed:

- Clean up dubious code in contrib/seg.  The restore() function
  assumed that the result of sprintf() with %e format would
  necessarily contain an 'e', which is false: what if the supplied
  number is an infinity or NaN?  If that did happen, we'd get a
  null-pointer-dereference core dump.  The case appears impossible
  currently, because seg_in() does not accept such values, and there
  are no seg-creating functions that would create one.  But it seems
  unwise to rely on it never happening in future.  Quite aside from
  that, the code was pretty ugly: it relied on modifying a static
  format string when it could use a "*" precision argument, and it
  used strtok() entirely gratuitously, and it stripped off trailing
  spaces by hand instead of just not asking for them to begin with.
  Coverity noticed the potential null pointer dereference (though I
  wonder why it didn't complain years ago, since this code is
  ancient).  Since this is just code cleanup and forestalling a
  hypothetical future bug, there seems no need for back-patching.
  http://git.postgresql.org/pg/commitdiff/a75a418d07bf852dc9fdb85ccfb39c763aa057a9

- Fix latent portability issue in pgwin32_dispatch_queued_signals().
  The first iteration of the signal-checking loop would compute
  sigmask(0) which expands to 1<<(-1) which is undefined behavior
  according to the C standard.  The lack of field reports of trouble
  suggest that it evaluates to 0 on all existing Windows compilers,
  but that's hardly something to rely on.  Since signal 0 isn't a
  queueable signal anyway, we can just make the loop iterate from 1
  instead, and save a few cycles as well as avoiding the undefined
  behavior.  In passing, avoid evaluating the volatile expression
  UNBLOCKED_SIGNAL_QUEUE twice in a row; there's no reason to waste
  cycles like that.  Noted by Aleksander Alekseev, though this isn't
  his proposed fix.  Back-patch to all supported branches.
  http://git.postgresql.org/pg/commitdiff/58666ed28ab59a2686ee08bc648b4e9959aacfce

- Introduce a LOG_SERVER_ONLY ereport level, which is never sent to
  client.  This elevel is useful for logging audit messages and
  similar information that should not be passed to the client.  It's
  equivalent to LOG in terms of decisions about logging priority in
  the postmaster log, but messages with this elevel will never be sent
  to the client.  In the current implementation, it's just an alias
  for the longstanding COMMERROR elevel (or more accurately, we've
  made COMMERROR an alias for this).  At some point it might be
  interesting to allow a LOG_ONLY flag to be attached to any elevel,
  but that would be considerably more complicated, and it's not clear
  there's enough use-cases to justify the extra work.  For now, let's
  just take the easy 90% solution.  David Steele, reviewed by Fabien
  Coelho, Petr Jelínek, and myself
  http://git.postgresql.org/pg/commitdiff/66229ac0040cf1e0f5b9d72271aa9feaf3b3a37e

- Add a \gexec command to psql for evaluation of computed queries.
  \gexec executes the just-entered query, like \g, but instead of
  printing the results it takes each field as a SQL command to send to
  the server.  Computing a series of queries to be executed is a
  fairly common thing, but up to now you always had to resort to
  kluges like writing the queries to a file and then inputting the
  file.  Now it can be done with no intermediate step.  The
  implementation is fairly straightforward except for its interaction
  with FETCH_COUNT.  ExecQueryUsingCursor isn't capable of being
  called recursively, and even if it were, its need to create a
  transaction block interferes unpleasantly with the desired behavior
  of \gexec after a failure of a generated query (i.e., that it can
  continue).  Therefore, disable use of ExecQueryUsingCursor when
  doing the master \gexec query.  We can still apply it to individual
  generated queries, however, and there might be some value in doing
  so.  While testing this feature's interaction with single-step mode,
  I (tgl) was led to conclude that SendQuery needs to recognize SIGINT
  (cancel_pressed) as a negative response to the single-step prompt.
  Perhaps that's a back-patchable bug fix, but for now I just included
  it here.  Corey Huinker, reviewed by Jim Nasby, Daniel Vérité, and
  myself
  http://git.postgresql.org/pg/commitdiff/2bbe9112aec60abc2d3b4c39e75d0cbdcaaa45e1

- Add a few comments about ANALYZE's strategy for collecting MCVs.
  Alex Shulgin complained that the underlying strategy wasn't all that
  apparent, particularly not the fact that we intentionally have two
  code paths depending on whether we think the column has a limited
  set of possible values or not.  Try to make it clearer.
  http://git.postgresql.org/pg/commitdiff/3c69b33f459f62fe6db66c386ef12620ea697f74

- Partially revert commit 3d3bf62f30200500637b24fdb7b992a99f9704c3.
  On reflection, the pre-existing logic in ANALYZE is specifically
  meant to compare the frequency of a candidate MCV against the
  estimated frequency of a random distinct value across the whole
  table.  The change to compare it against the average frequency of
  values actually seen in the sample doesn't seem very principled, and
  if anything it would make us less likely not more likely to consider
  a value an MCV.  So revert that, but keep the aspect of considering
  only nonnull values, which definitely is correct.  In passing,
  rename the local variables in these stanzas to "ndistinct_table", to
  avoid confusion with the "ndistinct" that appears at an outer scope
  in compute_scalar_stats.
  http://git.postgresql.org/pg/commitdiff/391159e03a8b69dd04a1432ceb800c7c4c3d608c

- Disallow newlines in parameter values to be set in ALTER SYSTEM.  As
  noted by Julian Schauder in bug #14063, the configuration-file
  parser doesn't support embedded newlines in string literals.  While
  there might someday be a good reason to remove that restriction,
  there doesn't seem to be one right now.  However, ALTER SYSTEM SET
  could accept strings containing newlines, since many of the
  variable-specific value-checking routines would just see a newline
  as whitespace.  This led to writing a postgresql.auto.conf file that
  was broken and had to be removed manually.  Pending a reason to work
  harder, just throw an error if someone tries this.  In passing, fix
  several places in the ALTER SYSTEM logic that failed to provide an
  errcode() for an ereport(), and thus would falsely log the failure
  as an internal XX000 error.  Back-patch to 9.4 where ALTER SYSTEM
  was introduced.
  http://git.postgresql.org/pg/commitdiff/99f3b5613bd1f145b5dbbe86000337bbe37fb094

- Fix PL/Python for recursion and interleaved set-returning functions.
  PL/Python failed if a PL/Python function was invoked recursively via
  SPI, since arguments are passed to the function in its global
  dictionary (a horrible decision that's far too ancient to undo) and
  it would delete those dictionary entries on function exit, leaving
  the outer recursion level(s) without any arguments.  Not deleting
  them would be little better, since the outer levels would then see
  the innermost level's arguments.  Since PL/Python uses ValuePerCall
  mode for evaluating set-returning functions, it's possible for
  multiple executions of the same SRF to be interleaved within a
  query.  PL/Python failed in such a case, because it stored only one
  iterator per function, directly in the function's PLyProcedure
  struct.  Moreover, one interleaved instance of the SRF would see
  argument values that should belong to another.  Hence, invent code
  for saving and restoring the argument entries.  To fix the recursion
  case, we only need to save at recursive entry and restore at
  recursive exit, so the overhead in non-recursive cases is
  negligible.  To fix the SRF case, we have to save when suspending a
  SRF and restore when resuming it, which is potentially not
  negligible; but fortunately this is mostly a matter of manipulating
  Python object refcounts and should not involve much physical data
  copying.  Also, store the Python iterator and saved argument values
  in a structure associated with the SRF call site rather than the
  function itself.  This requires adding a memory context deletion
  callback to ensure that the SRF state is cleaned up if the calling
  query exits before running the SRF to completion.  Without that we'd
  leak a refcount to the iterator object in such a case, resulting in
  session-lifespan memory leakage.  (In the pre-existing code, there
  was no memory leak because there was only one iterator pointer, but
  what would happen is that the previous iterator would be resumed by
  the next query attempting to use the SRF.  Hardly the semantics we
  want.) We can buy back some of whatever overhead we've added by
  getting rid of PLy_function_delete_args(), which seems a useless
  activity: there is no need to delete argument entries from the
  global dictionary on exit, since the next time anyone would see the
  global dict is on the next fresh call of the PL/Python function, at
  which time we'd overwrite those entries with new arg values anyway.
  Also clean up some really ugly coding in the SRF implementation,
  including such gems as returning directly out of a PG_TRY block.
  (The only reason that failed to crash hard was that all existing
  call sites immediately exited their own PG_TRY blocks, popping the
  dangling longjmp pointer before there was any chance of it being
  used.) In principle this is a bug fix; but it seems a bit too
  invasive relative to its value for a back-patch, and besides the fix
  depends on memory context callbacks so it could not go back further
  than 9.5 anyway.  Alexey Grishchenko and Tom Lane
  http://git.postgresql.org/pg/commitdiff/1d2fe56e42640613781fc17ab1534fd0551de9bd

- Run pgindent on a batch of (mostly-planner-related) source files.
  Getting annoyed at the amount of unrelated chatter I get from
  pgindent'ing Rowley's unique-joins patch.  Re-indent all the files
  it touches.
  http://git.postgresql.org/pg/commitdiff/de94e2af184e25576b13cbda8cf825118835d1cd

- Refactor join_is_removable() to separate out distinctness-proving
  logic.  Extracted from pending unique-join patch, since this is a
  rather large delta but it's simply moving code out into
  separately-accessible subroutines.  I (tgl) did choose to add a bit
  more logic to rel_supports_distinctness, so that it verifies that
  there's at least one potentially usable unique index rather than
  just checking indexlist != NIL.  Otherwise there's no functional
  change here.  David Rowley
  http://git.postgresql.org/pg/commitdiff/f338dd7585cab45da9053e883ad65a440a99d3be

- Fix multiple bugs in tablespace symlink removal.  Don't try to
  examine S_ISLNK(st.st_mode) after a failed lstat().  It's undefined.
  Also, if the lstat() reported ENOENT, we do not wish that to be a
  hard error, but the code might nonetheless treat it as one (giving
  an entirely misleading error message, too) depending on
  luck-of-the-draw as to what S_ISLNK() returned.  Don't throw error
  for ENOENT from rmdir(), either.  (We're not really expecting ENOENT
  because we just stat'd the file successfully; but if we're going to
  allow ENOENT in the symlink code path, surely the directory code
  path should too.) Generate an appropriate errcode for
  its-the-wrong-type-of-file complaints.  (ERRCODE_SYSTEM_ERROR
  doesn't seem appropriate, and failing to write errcode() around it
  certainly doesn't work, and not writing an errcode at all is not per
  project policy.) Valgrind noticed the undefined S_ISLNK result; the
  other problems emerged while reading the code in the area.  All of
  this appears to have been introduced in 8f15f74a44f68f9c.
  Back-patch to 9.5 where that commit appeared.
  http://git.postgresql.org/pg/commitdiff/93c301fc4ff7d4f06bff98fea8db47ce67f28155

- Add BSD authentication method.  Create a "bsd" auth method that
  works the same as "password" so far as clients are concerned, but
  calls the BSD Authentication service to check the password.  This is
  currently only available on OpenBSD.  Marisa Emerson, reviewed by
  Thomas Munro
  http://git.postgresql.org/pg/commitdiff/34c33a1f00259ce5e3e1d1b4a784037adfca6057

- Fix unstable regression test output.  Output order from the
  pg_indexes view might vary depending on the phase of the moon, so
  add ORDER BY to ensure stable results of tests added by commit
  386e3d7609c49505e079c40c65919d99feb82505.  Per buildfarm.
  http://git.postgresql.org/pg/commitdiff/690c543550b0d2852060c18d270cdb534d339d9a

- Run pgindent on generic_xlog.c.  This code desperately needs some
  micro-optimization, and I'd like it to be formatted a bit more
  nicely while I work on it.
  http://git.postgresql.org/pg/commitdiff/2dd318d277b8e1d8269b030f545240193943162f

- Code review/prettification for generic_xlog.c.  Improve commentary,
  use more specific names for the delta fields, const-ify pointer
  arguments where possible, avoid assuming that initializing only the
  first element of a local array will guarantee that the remaining
  elements end up as we need them.  (I think that code in generic_redo
  actually worked, but only because InvalidBuffer is zero; this is a
  particularly ugly way of depending on that ...)
  http://git.postgresql.org/pg/commitdiff/db03cf375d602e417eda6b7a55eead91618e1398

- Get rid of blinsert()'s use of GenericXLogUnregister().  That
  routine is dangerous, and unnecessary once we get rid of this one
  caller.  In passing, fix failure to clean up temp memory context, or
  switch back to caller's context, during slowest exit path.
  http://git.postgresql.org/pg/commitdiff/80cf18910c8edf2575c306dde9ead192bdb0863a

- Get rid of GenericXLogUnregister().  This routine is unsafe as
  implemented, because it invalidates the page image pointers returned
  by previous GenericXLogRegister() calls.  Rather than complicate the
  API or the implementation to avoid that, let's just get rid of it;
  the use-case for having it seems much too thin to justify a lot of
  work here.  While at it, do some wordsmithing on the SGML docs for
  generic WAL.
  http://git.postgresql.org/pg/commitdiff/08e785436f84f8824149a2182b0cb9ce2c28e31d

- Fix PL/Python ereport() test to work on Python 2.3.  Per buildfarm.
  Pavel Stehule
  http://git.postgresql.org/pg/commitdiff/c7a141a9866b8c15d9e3b6fd5310e54837900394

- Micro-optimize GenericXLogFinish().  Make the inner comparison loops
  of computeDelta() as tight as possible by pulling considerations of
  valid and invalid ranges out of the inner loops, and extending a
  match or non-match detection as far as possible before deciding what
  to do next.  To keep this tractable, give up the possibility of
  merging fragments across the pd_lower to pd_upper gap.  The fraction
  of pages where that could happen (ie, there are 4 or fewer bytes in
  the gap, *and* data changes immediately adjacent to it on both
  sides) is too small to be worth spending cycles on.  Also, avoid two
  BLCKSZ-length memcpy()s by computing the delta before moving data
  into the target buffer, instead of after.  This doesn't save nearly
  as many cycles as being tenser about computeDelta(), but it still
  seems worth doing.  On my machine, this patch cuts a full 40% off
  the runtime of contrib/bloom's regression test.
  http://git.postgresql.org/pg/commitdiff/68689c66efcda6f217119432edfbdf95a50b26e2

- Further minor improvement in generic_xlog.c: always say
  REGBUF_STANDARD.  Since we're requiring pages handled by
  generic_xlog.c to be standard format, specify REGBUF_STANDARD when
  doing a full-page image, so that xloginsert.c can compress out the
  "hole" between pd_lower and pd_upper.  Given the current API in
  which this path will be taken only for a newly initialized page, the
  hole is likely to be particularly large in such cases, so that this
  oversight could easily be performance-significant.  I don't notice
  any particular change in the runtime of contrib/bloom's regression
  test, though.
  http://git.postgresql.org/pg/commitdiff/660d5fb856c61df2de2cedb26249404ffc58cb89

- Improve contrib/bloom regression test using code coverage info.
  Originally, this test created a 100000-row test table, which made it
  run rather slowly compared to other contrib tests.  Investigation
  with gcov showed that we got no further improvement in code coverage
  after the first 700 or so rows, making the large table 99% a waste
  of time.  Cut it back to 2000 rows to fix the runtime problem and
  still leave some headroom for testing behaviors that may appear
  later.  A closer look at the gcov results showed that the main
  coverage omissions in contrib/bloom occurred because the test never
  filled more than one entry in the notFullPage array; which is
  unsurprising because it exercised index cleanup only in the scenario
  of complete table deletion, allowing every page in the index to
  become deleted rather than not-full.  Add testing that allows the
  not-full path to be exercised as well.  Also, test the amvalidate
  function, because blvalidate.c had zero coverage without that, and
  besides it's a good idea to check for mistakes in the bloom opclass
  definitions.
  http://git.postgresql.org/pg/commitdiff/cf223c3bf5ba16232147c66b5fef4037aafe747c

- Fix access-to-already-freed-memory issue in plpython's error
  handling.  PLy_elog() could attempt to access strings that Python
  had already freed, because the strings that PLy_get_spi_error_data()
  returns are simply pointers into storage associated with the error
  "val" PyObject.  That's fine at the instant PLy_get_spi_error_data()
  returns them, but just after that PLy_traceback() intentionally
  releases the only refcount on that object, allowing it to be freed
  --- so that the strings we pass to ereport() are dangling pointers.
  In principle this could result in garbage output or a coredump.  In
  practice, I think the risk is pretty low, because there are no
  Python operations between where we decrement that refcount and where
  we use the strings (and copy them into PG storage), and thus no
  reason for Python to recycle the storage.  Still, it's clearly
  hazardous, and it leads to Valgrind complaints when running under a
  Valgrind that hasn't been lobotomized to ignore Python memory
  allocations.  The code was a mess anyway: we fetched the error data
  out of Python (clearing Python's error indicator) with PyErr_Fetch,
  examined it, pushed it back into Python with PyErr_Restore
  (re-setting the error indicator), then immediately pulled it back
  out with another PyErr_Fetch.  Just to confuse matters even more,
  there were some gratuitous-and-yet-hazardous PyErr_Clear calls in
  the "examine" step, and we didn't get around to doing
  PyErr_NormalizeException until after the second PyErr_Fetch, making
  it even less clear which object was being manipulated where and
  whether we still had a refcount on it.  (If PyErr_NormalizeException
  did substitute a different "val" object, it's possible that the
  problem could manifest for real, because then we'd be doing assorted
  Python stuff with no refcount on the object we have string pointers
  into.) So, rearrange all that into some semblance of sanity, and
  don't decrement the refcount on the Python error objects until the
  end of PLy_elog().  In HEAD, I failed to resist the temptation to
  reformat some messy bits from 5c3c3cd0a3046339 along the way.
  Back-patch as far as 9.2, because the code is substantially the same
  that far back.  I believe that 9.1 has the bug as well; but the code
  around it is rather different and I don't want to take a chance on
  breaking something for what seems a low-probability problem.
  http://git.postgresql.org/pg/commitdiff/7e3bb080387f4143cdc908bf97daf9a8abdc445f

- Clean up foreign-key caching code in planner.  Coverity complained
  that the code added by 015e88942aa50f0d lacked an error check for
  SearchSysCache1 failures, which it should have.  But the code was
  pretty duff in other ways too, including failure to think about
  whether it could really cope with arrays of different lengths.
  http://git.postgresql.org/pg/commitdiff/5306df2831ab012d8008691f833457bc299962aa

- pg_dump: add missing "destroyPQExpBuffer(query)" in
  dumpForeignServer().  Coverity complained about this resource leak
  (why now, I don't know, since it's been like that a long time).  Our
  general policy in pg_dump is that PQExpBuffers are worth cleaning
  up, so do it here too.  But don't bother with a back-patch, because
  it seems unlikely that very many databases contain enough FOREIGN
  SERVER objects to notice.
  http://git.postgresql.org/pg/commitdiff/074050f16a2db9b5ebe5c9f8fdb211cbb810e746

- Add comment about intentional fallthrough in switch.  Coverity
  complained about an apparent missing "break" in a switch added by
  bb140506df605fab.  The human-readable comments are pretty clear that
  this is intentional, but add a standard /* FALL THRU */ comment to
  make it clear to tools too.
  http://git.postgresql.org/pg/commitdiff/1630f5b92a3a00aff5674f31af1d418628a00ac7

- Fix poorly thought-through code from commit 5c3c3cd0a3046339.  It's
  not entirely clear to me whether PyString_AsString can return null
  (looks like the answer might vary between Python 2 and 3).  But in
  any case, this code's attempt to cope with the possibility was quite
  broken, because pstrdup() neither allows a null argument nor ever
  returns a null.  Moreover, the code below this point assumes that
  "message" is a palloc'd string, which would not be the case for a
  dgettext result.  Fix both problems by doing the pstrdup step
  separately.
  http://git.postgresql.org/pg/commitdiff/f73b2bbbdcb387aa90ff619fe03d1924ed82b868

Dean Rasheed pushed:

- Improve estimate of distinct values in estimate_num_groups().  When
  adjusting the estimate for the number of distinct values from a rel
  in a grouped query to take into account the selectivity of the rel's
  restrictions, use a formula that is less likely to produce
  under-estimates.  The old formula simply multiplied the number of
  distinct values in the rel by the restriction selectivity, which
  would be correct if the restrictions were fully correlated with the
  grouping expressions, but can produce significant under-estimates in
  cases where they are not well correlated.  The new formula is based
  on the random selection probability, and so assumes that the
  restrictions are not correlated with the grouping expressions. This
  is guaranteed to produce larger estimates, and of course risks
  over-estimating in cases where the restrictions are correlated, but
  that has less severe consequences than under-estimating, which might
  lead to a HashAgg that consumes an excessive amount of memory.  This
  could possibly be improved upon in the future by identifying
  correlated restrictions and using a hybrid of the old and new
  formulae.  Author: Tomas Vondra, with some hacking be me
  Reviewed-by: Mark Dilger, Alexander Korotkov, Dean Rasheed and Tom
  Lane Discussion:
  http://www.postgresql.org/message-id/flat/56CD0381.5060502@2ndquadrant.com
  http://git.postgresql.org/pg/commitdiff/84f9a35e398f863c62440d3f82fc57b4fedc5d08

Teodor Sigaev pushed:

- Fix typo.  Michael Paquier
  http://git.postgresql.org/pg/commitdiff/eb7308d29875df773b5b52b06ed3d8b60f1b8242

- fix typo.  Andreas Ulbrich
  http://git.postgresql.org/pg/commitdiff/9b27aebe7124210c1b0dbacac657edfefa16a006

- Add jsonb_insert.  It inserts a new value into an jsonb array at
  arbitrary position or a new key to jsonb object.  Author: Dmitry
  Dolgov Reviewers: Petr Jelinek, Vitaly Burovoy, Andrew Dunstan
  http://git.postgresql.org/pg/commitdiff/0b62fd036e1ac48a8432bb9664b21e1f036c1b08

- Make testing of phraseto_tsquery independ from value of
  default_text_search_config variable.  Per skink buldfarm member
  http://git.postgresql.org/pg/commitdiff/a7ace3b6d96c7a1539ed0700865d320258a12f73

- Zeroing unused parts ducring tsquery construction.  Per
  investigation failure skink buildfarm member and
  RANDOMIZE_ALLOCATED_MEMORY help
  http://git.postgresql.org/pg/commitdiff/3308467905aa157139d24375850cfe49ee90a0cf

- Rename comparePos() to compareWordEntryPos().  Rename comparePos()
  to compareWordEntryPos() to prevent export of too generic name.  Per
  gripe from Tom Lane.
  http://git.postgresql.org/pg/commitdiff/4e55b3f0335c2aa658cd9d1fda4dea2a1f9ab80d

- Phrase full text search.  Patch introduces new text search operator
  (<-> or <DISTANCE>) into tsquery.  On-disk and binary in/out format
  of tsquery are backward compatible.  It has two side effect: change
  order for tsquery, so, users, who has a btree index over tsquery,
  should reindex it, less number of parenthesis in tsquery output, and
  tsquery becomes more readable Authors: Teodor Sigaev, Oleg Bartunov,
  Dmitry Ivanov Reviewers: Alexander Korotkov, Artur Zakirov
  http://git.postgresql.org/pg/commitdiff/bb140506df605fab58f48926ee1db1f80bdafb59

- Enhanced custom error in PLPythonu.  Patch adds a new, more rich,
  way to emit error message or exception from PL/Pythonu code.
  Author: Pavel Stehule Reviewers: Catalin Iacob, Peter Eisentraut,
  Jim Nasby
  http://git.postgresql.org/pg/commitdiff/5c3c3cd0a3046339597a03bc708cb5530dc07059

- Restore original tsquery operation numbering.  As noticed by Tom
  Lane changing operation's number in commit
  bb140506df605fab58f48926ee1db1f80bdafb59 causes on-disk format
  incompatibility.  Revert to previous numbering, that is reason to
  add special array to store priorities of operation. Also it reverts
  order of tsquery to previous.  Author: Dmitry Ivanov
  http://git.postgresql.org/pg/commitdiff/1ec4c7c055ca045c5df6352a4cdacd9aa778e598

- Fix output of regression test of contrib/tsearch2.  Just forget to
  add in 1ec4c7c055ca045c5df6352a4cdacd9aa778e598
  http://git.postgresql.org/pg/commitdiff/38627f687823eae57e932c3b234656342403e909

- Fix possible use of uninitialised value in ts_headline() Found
  during investigation of failure of skink buildfarm member and its
  valgrind report.  Backpatch to all supported branches
  http://git.postgresql.org/pg/commitdiff/cb0c8cbf316f9362c11d7a8356e6f459258ae78e

- Revert CREATE INDEX ... INCLUDING ...  It's not ready yet, revert
  two commits 690c543550b0d2852060c18d270cdb534d339d9a - unstable test
  output 386e3d7609c49505e079c40c65919d99feb82505 - patch itself
  http://git.postgresql.org/pg/commitdiff/8b99edefcab1e82c43139a2c7dc06d31fb27b3e4

- CREATE INDEX ... INCLUDING (column[, ...]).  Now indexes (but only
  B-tree for now) can contain "extra" column(s) which doesn't
  participate in index structure, they are just stored in leaf tuples.
  It allows to use index only scan by using single index instead of
  two or more indexes.  Author: Anastasia Lubennikova with minor
  editorializing by me Reviewers: David Rowley, Peter Geoghegan, Jeff
  Janes
  http://git.postgresql.org/pg/commitdiff/386e3d7609c49505e079c40c65919d99feb82505

Álvaro Herrera pushed:

- Silence compiler warning.  Reported by Peter Eisentraut to occur on
  32bit systems
  http://git.postgresql.org/pg/commitdiff/c9ff752a854b687fc0a05fd4aba1066028ec5495

- Display WAL pointer in rm_redo error callback.  This makes it easier
  to identify the source of a recovery problem in case of a bug or
  data corruption.
  http://git.postgresql.org/pg/commitdiff/890614d2b35bd20468352043870edc7f24a7b8ec

- Support ALTER THING .. DEPENDS ON EXTENSION.  This introduces a new
  dependency type which marks an object as depending on an extension,
  such that if the extension is dropped, the object automatically goes
  away; and also, if the database is dumped, the object is included in
  the dump output.  Currently the grammar supports this for indexes,
  triggers, materialized views and functions only, although the
  utility code is generic so adding support for more object types is a
  matter of touching the parser rules only.  Author: Abhijit Menon-Sen
  Reviewed-by: Alexander Korotkov, Álvaro Herrera Discussion:
  http://www.postgresql.org/message-id/20160115062649.GA5068@toroid.org
  http://git.postgresql.org/pg/commitdiff/f2fcad27d59c8e5c48f8fa0a96c8355e40f24273

- Fix broken ALTER INDEX documentation.  Commit b8a91d9d1c put the
  description of the new IF EXISTS clause in the wrong place -- move
  it where it belongs.  Backpatch to 9.2.
  http://git.postgresql.org/pg/commitdiff/2143f5e127903cb50c10537fc22392083cb033b7

- Support \crosstabview in psql.  \crosstabview is a completely
  different way to display results from a query: instead of a vertical
  display of rows, the data values are placed in a grid where the
  column and row headers come from the data itself, similar to a
  spreadsheet.  The sort order of the horizontal header can be
  specified by using another column in the query, and the vertical
  header determines its ordering from the order in which they appear
  in the query.  This only allows displaying a single value in each
  cell.  If more than one value correspond to the same cell, an error
  is thrown.  Merging of values can be done in the query itself, if
  necessary.  This may be revisited in the future.  Author: Daniel
  Verité Reviewed-by: Pavel Stehule, Dean Rasheed
  http://git.postgresql.org/pg/commitdiff/c09b18f21c52cbcf8718d6c267c84fcfea3739a9

- Move \crosstabview regression tests to a separate file.  It cannot
  run in the same parallel group as misc, because it creates a table
  which is unpredictably visible in that test.  Per buildfarm member
  crake.
  http://git.postgresql.org/pg/commitdiff/1ff3f420d470fae46759e948a20e9550af012816

- Fix possible NULL dereference in ExecAlterObjectDependsStmt.  I used
  the wrong variable here.  Doesn't make a difference today because
  the only plausible caller passes a non-NULL variable, but someday it
  will be wrong, and even today's correctness is subtle: the caller
  that does pass a NULL is never invoked because of object type
  constraints.  Surely not a condition to rely on.  Noted by Coverity
  http://git.postgresql.org/pg/commitdiff/bd905a0d0416628b4aef153463c1f5e5b80b3e96

Peter Eisentraut pushed:

- Fix error message from wal_level value renaming found by Ian
  Barwick.
  http://git.postgresql.org/pg/commitdiff/4dcd4da98c786c48b0dbf129c8f7ea592c34a185

- pg_dump: Add table qualifications to some tags.  Some object types
  have names that are only unique for one table.  But for those we
  generally didn't put the table name into the dump TOC tag.  So it
  was impossible to identify these objects if the same name was used
  for multiple tables.  This affects policies, column defaults,
  constraints, triggers, and rules.  Fix by adding the table name to
  the TOC tag, so that it now reads "$schema $table $object".
  Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
  http://git.postgresql.org/pg/commitdiff/3b3fcc4eeaeecff315420833975e7c87d760bfe1

- Set PAM_RHOST item for PAM authentication.  The PAM_RHOST item is
  set to the remote IP address or host name and can be used by PAM
  modules.  A pg_hba.conf option is provided to choose between IP
  address and resolved host name.  From: Grzegorz Sampolski
  <grzsmp@gmail.com> Reviewed-by: Haribabu Kommi
  <kommi.haribabu@gmail.com>
  http://git.postgresql.org/pg/commitdiff/2f1d2b7a75fecad25295cb3f453503eb6a176d4f

- Fix printf format.
  http://git.postgresql.org/pg/commitdiff/8b737f90843157706b8b5eb401b2aff08da77781

- Replace printf format %i by %d.  see also
  ce8d7bb6440710058503d213b2aafcdf56a5b481
  http://git.postgresql.org/pg/commitdiff/339025c68f95d3cb2c42478109cafeaf414c7fe0

- Distrust external OpenSSL clients; clear err queue.  OpenSSL has an
  unfortunate tendency to mix per-session state error handling with
  per-thread error handling.  This can cause problems when programs
  that link to libpq with OpenSSL enabled have some other use of
  OpenSSL; without care, one caller of OpenSSL may cause problems for
  the other caller.  Backend code might similarly be affected, for
  example when a third party extension independently uses OpenSSL
  without taking the appropriate precautions.  To fix, don't trust
  other users of OpenSSL to clear the per-thread error queue.
  Instead, clear the entire per-thread queue ahead of certain I/O
  operations when it appears that there might be trouble (these I/O
  operations mostly need to call SSL_get_error() to check for success,
  which relies on the queue being empty).  This is slightly
  aggressive, but it's pretty clear that the other callers have a very
  dubious claim to ownership of the per-thread queue.  Do this is both
  frontend and backend code.  Finally, be more careful about clearing
  our own error queue, so as to not cause these problems ourself.
  It's possibly that control previously did not always reach
  SSLerrmessage(), where ERR_get_error() was supposed to be called to
  clear the queue's earliest code.  Make sure ERR_get_error() is
  always called, so as to spare other users of OpenSSL the possibility
  of similar problems caused by libpq (as opposed to problems caused
  by a third party OpenSSL library like PHP's OpenSSL extension).
  Again, do this is both frontend and backend code.  See bug #12799
  and https://bugs.php.net/bug.php?id=68276 Based on patches by Dave
  Vitek and Peter Eisentraut.  From: Peter Geoghegan <pg@bowt.ie>
  http://git.postgresql.org/pg/commitdiff/7c7d4fddab82dc756d8caa67b1b31fcdde355aab

Magnus Hagander pushed:

- Fix typo.  Etsuro Fujita
  http://git.postgresql.org/pg/commitdiff/9457b591b949d3c256dd91043df71fb11657227a

- Implement backup API functions for non-exclusive backups.
  Previously non-exclusive backups had to be done using the
  replication protocol and pg_basebackup. With this commit it's now
  possible to make them using pg_start_backup/pg_stop_backup as well,
  as long as the backup program can maintain a persistent connection
  to the database.  Doing this, backup_label and tablespace_map are
  returned as results from pg_stop_backup() instead of being written
  to the data directory.  This makes the server safe from a crash
  during an ongoing backup, which can be a problem with exclusive
  backups.  The old syntax of the functions remain and work exactly as
  before, but since the new syntax is safer this should eventually be
  deprecated and removed.  Only reference documentation is included.
  The main section on backup still needs to be rewritten to cover
  this, but since that is already scheduled for a separate large
  rewrite, it's not included in this patch.  Reviewed by David Steele
  and Amit Kapila
  http://git.postgresql.org/pg/commitdiff/7117685461af50f50c03f43e6a622284c8d54694

- Add authentication parameters compat_realm and upn_usename for SSPI.
  These parameters are available for SSPI authentication only, to make
  it possible to make it behave more like "normal gssapi", while
  making it possible to maintain compatibility.  compat_realm is on by
  default, but can be turned off to make the authentication use the
  full Kerberos realm instead of the NetBIOS name.  upn_username is
  off by default, and can be turned on to return the users Kerberos
  UPN rather than the SAM-compatible name (a user in Active Directory
  can have both a legacy SAM-compatible username and a new Kerberos
  one. Normally they are the same, but not always) Author: Christian
  Ullrich Reviewed by: Robbie Harwood, Alvaro Herrera, me
  http://git.postgresql.org/pg/commitdiff/35e2e357cb054dc9e5d890fe754c56f0722f015e

Robert Haas pushed:

- Add parallel query support functions for assorted aggregates.  This
  lets us use parallel aggregate for a variety of useful cases that
  didn't work before, like sum(int8), sum(numeric), several versions
  of avg(), and various other functions.  Add some regression tests,
  as well, testing the general sanity of these and future catalog
  entries.  David Rowley, reviewed by Tomas Vondra, with a few further
  changes by me.
  http://git.postgresql.org/pg/commitdiff/11c8669c0cc7abc7a7702594cf13452c378d2517

- Align all shared memory allocations to cache line boundaries.
  Experimentation shows this only costs about 6kB, which seems well
  worth it given the major performance effects that can be caused by
  insufficient alignment, especially on larger systems.  Discussion:
  14166.1458924422@sss.pgh.pa.us
  http://git.postgresql.org/pg/commitdiff/09adc9a8c09c9640de05c7023b27fb83c761e91c

- Fix parallel-safety code for parallel aggregation.
  has_parallel_hazard() was ignoring the proparallel markings for
  aggregates, which is no good.  Fix that.  There was no way to mark
  an aggregate as actually being parallel-safe, either, so add a
  PARALLEL option to CREATE AGGREGATE.  Patch by me, reviewed by David
  Rowley.
  http://git.postgresql.org/pg/commitdiff/41ea0c23761ca108e2f08f6e3151e3cb1f9652a1

- Extend relations multiple blocks at a time to improve scalability.
  Contention on the relation extension lock can become quite fierce
  when multiple processes are inserting data into the same relation at
  the same time at a high rate.  Experimentation shows the extending
  the relation multiple blocks at a time improves scalability.  Dilip
  Kumar, reviewed by Petr Jelinek, Amit Kapila, and me.
  http://git.postgresql.org/pg/commitdiff/719c84c1be51f3d3fe6049b77ddbaa0c4b58a9a9

- Attempt to fix breakage due to declaration following code.  Per Tom
  Lane and the buildfarm.
  http://git.postgresql.org/pg/commitdiff/b0b64f65054e6b858b845b46298a624aaaea1deb

- Use quicksort, not replacement selection, for external sorting.  We
  still use replacement selection for the first run of the sort only
  and only when the number of tuples is relatively small.  Otherwise,
  the first run, and subsequent runs in all cases, are produced using
  quicksort.  This tends to be faster except perhaps for very small
  amounts of working memory.  Peter Geoghegan, reviewed by Tomas
  Vondra, Jeff Janes, Mithun Cy, Greg Stark, and me.
  http://git.postgresql.org/pg/commitdiff/0711803775a37e0bf39d7efdd1e34d9d7e640ea1

- Add a 'parallel_degree' reloption.  The code that estimates what
  parallel degree should be uesd for the scan of a relation is
  currently rather stupid, so add a parallel_degree reloption that can
  be used to override the planner's rather limited judgement.  Julien
  Rouhaud, reviewed by David Rowley, James Sewell, Amit Kapila, and
  me.  Some further hacking by me.
  http://git.postgresql.org/pg/commitdiff/25fe8b5f1ac93c3ec01519854e4f554b2e57a926

- Document which aggregates support partial mode.  David Rowley,
  reviewed by Tomas Vondra
  http://git.postgresql.org/pg/commitdiff/752b948dfca23ca8229d4490adc1d54be41c09a3

- Add combine functions for various floating-point aggregates.  This
  allows parallel aggregation to use them.  It may seem surprising
  that we use float8_combine for both float4_accum and float8_accum
  transition functions, but that's because those functions differ only
  in the type of the non-transition-state argument.  Haribabu Kommi,
  reviewed by David Rowley and Tomas Vondra
  http://git.postgresql.org/pg/commitdiff/af025eed536d3842d085ed9e4f9107eb976575cc

Fujii Masao pushed:

- Support multiple synchronous standby servers.  Previously
  synchronous replication offered only the ability to confirm that all
  changes made by a transaction had been transferred to at most one
  synchronous standby server.  This commit extends synchronous
  replication so that it supports multiple synchronous standby
  servers. It enables users to consider one or more standby servers as
  synchronous, and increase the level of transaction durability by
  ensuring that transaction commits wait for replies from all of those
  synchronous standbys.  Multiple synchronous standby servers are
  configured in synchronous_standby_names which is extended to support
  new syntax of 'num_sync ( standby_name [ , ... ] )', where num_sync
  specifies the number of synchronous standbys that transaction
  commits need to wait for replies from and standby_name is the name
  of a standby server.  The syntax of 'standby_name [ , ... ]' which
  was used in 9.5 or before is also still supported. It's the same as
  new syntax with num_sync=1.  This commit doesn't include "quorum
  commit" feature which was discussed in pgsql-hackers. Synchronous
  standbys are chosen based on their priorities.
  synchronous_standby_names determines the priority of each standby
  for being chosen as a synchronous standby. The standbys whose names
  appear earlier in the list are given higher priority and will be
  considered as synchronous. Other standby servers appearing later in
  this list represent potential synchronous standbys.  The regression
  test for multiple synchronous standbys is not included in this
  commit. It should come later.  Authors: Sawada Masahiko, Beena
  Emerson, Michael Paquier, Fujii Masao Reviewed-By: Kyotaro
  Horiguchi, Amit Kapila, Robert Haas, Simon Riggs, Amit Langote,
  Thomas Munro, Sameer Thakur, Suraj Kharage, Abhijit Menon-Sen,
  Rajeev Rastogi Many thanks to the various individuals who were
  involved in discussing and developing this feature.
  http://git.postgresql.org/pg/commitdiff/989be0810dffd08b54e1caecec0677608211c339

- Use proper format specifier %X/%X for LSN, again.  Commit cee31f5
  fixed this problem, but commit 989be08 accidentally reverted the
  fix.  Thomas Munro
  http://git.postgresql.org/pg/commitdiff/ead9963c471ccde50ff220e8294ea11a57eee91c

- Fix a couple of places in doc that implied there was only one sync
  standby.  Thomas Munro
  http://git.postgresql.org/pg/commitdiff/8643b91ecf8f47a1307df4a00d66b2fceada0d6f

- Add regression tests for multiple synchronous standbys.  Authors:
  Suraj Kharage, Michael Paquier, Masahiko Sawada, refactored by me
  Reviewed-By: Kyotaro Horiguchi
  http://git.postgresql.org/pg/commitdiff/196b72fb9a5556c66f2b012cc4e869175a3049fa

Simon Riggs pushed:

- Revert bf08f2292ffca14fd133aa0901d1563b6ecd6894.  Remove recent
  changes to logging XLOG_RUNNING_XACTS by request.
  http://git.postgresql.org/pg/commitdiff/cac0e36682970ec1276d3da3d3ee37325544a2bb

- Avoid archiving XLOG_RUNNING_XACTS on idle server.  If
  archive_timeout > 0 we should avoid logging XLOG_RUNNING_XACTS if
  idle.  Bug 13685 reported by Laurence Rowe, investigated in detail
  by Michael Paquier, though this is not his proposed fix.
  20151016203031.3019.72930@wrigleys.postgresql.org Simple
  non-invasive patch to allow later backpatch to 9.4 and 9.5
  http://git.postgresql.org/pg/commitdiff/bf08f2292ffca14fd133aa0901d1563b6ecd6894

- Modify test_decoding/messages to remove non-ascii chars
  http://git.postgresql.org/pg/commitdiff/d25379eb23383f1d2f969e65e0332b47c19aea94

- Generic Messages for Logical Decoding.  API and mechanism to allow
  generic messages to be inserted into WAL that are intended to be
  read by logical decoding plugins. This commit adds an optional new
  callback to the logical decoding API.  Messages are either text or
  bytea. Messages can be transactional, or not, and are identified by
  a prefix to allow multiple concurrent decoding plugins.  (Not to be
  confused with Generic WAL records, which are intended to allow crash
  recovery of extensible objects.) Author: Petr Jelinek and Andres
  Freund Reviewers: Artur Zakirov, Tomas Vondra, Simon Riggs
  Discussion: 5685F999.6010202@2ndquadrant.com
  http://git.postgresql.org/pg/commitdiff/3fe3511d05127cc024b221040db2eeb352e7d716

- Load FK defs into relcache for use by planner.  Fastpath ignores
  this if no triggers defined.  Author: Tomas Vondra, with fastpath
  and comments added by me Reviewers: David Rowley, Simon Riggs
  http://git.postgresql.org/pg/commitdiff/015e88942aa50f0d419ddac00e63bb06d6e62e86

- Use Foreign Key relationships to infer multi-column join
  selectivity.  In cases where joins use multiple columns we currently
  assess each join separately causing gross mis-estimates for join
  cardinality.  This patch adds use of FK information for the first
  time into the planner. When FKs are present and we have multi-column
  join information, plan estimates will be drastically improved. Cases
  with multiple FKs are handled, though partial matches are ignored
  currently.  Net effect is substantial performance improvements for
  joins in many common cases. Additional planning time is isolated to
  cases that are currently performing poorly, measured at 0.08 - 0.15
  ms.  Please watch for planner performance regressions; circumstances
  seem unlikely but the law of unintended consequences may apply
  somewhen.  Additional complex tests welcome to prove this before
  release.  Tests can be performed using SET enable_fkey_estimates =
  on | off using scripts provided during Hackers discussions, message
  id: 552335D9.3090707@2ndquadrant.com Authors: Tomas Vondra and David
  Rowley Reviewed and tested by Simon Riggs, adding comments only
  http://git.postgresql.org/pg/commitdiff/137805f89acb361144ec98d9847e26d2848aa57e

Stephen Frost pushed:

- Add new catalog called pg_init_privs.  This new catalog holds the
  privileges which the system was initialized with at initdb time,
  along with any permissions set by extensions at CREATE EXTENSION
  time.  This allows pg_dump (and any other similar use-cases) to
  detect when the privileges set on initdb-created or
  extension-created objects have been changed from what they were set
  to at initdb/extension-creation time and handle those changes
  appropriately.  Reviews by Alexander Korotkov, Jose Luis Tallon
  http://git.postgresql.org/pg/commitdiff/6c268df1276e9dd73e4d2cc89cf8787e8f186bda

- In pg_dump, use a bitmap to represent what to include.  pg_dump has
  historically used a simple boolean 'dump' value to indicate if a
  given object should be included in the dump or not.  Instead, use a
  bitmap which breaks down the components of an object into their
  distinct pieces and use that bitmap to only include the components
  requested.  This does not include any behavioral change, but is in
  preperation for the change to dump out just ACLs for objects in
  pg_catalog.  Reviews by Alexander Korotkov, Jose Luis Tallon
  http://git.postgresql.org/pg/commitdiff/a9f0e8e5a2e779a888988cb64479a6723f668c84

- In pg_dump, include pg_catalog and extension ACLs, if changed.  Now
  that all of the infrastructure exists, add in the ability to dump
  out the ACLs of the objects inside of pg_catalog or the ACLs for
  objects which are members of extensions, but only if they have been
  changed from their original values.  The original values are tracked
  in pg_init_privs.  When pg_dump'ing 9.6-and-above databases, we will
  dump out the ACLs for all objects in pg_catalog and the ACLs for all
  extension members, where the ACL has been changed from the original
  value which was set during either initdb or CREATE EXTENSION.  This
  should not change dumps against pre-9.6 databases.  Reviews by
  Alexander Korotkov, Jose Luis Tallon
  http://git.postgresql.org/pg/commitdiff/23f34fa4ba358671adab16773e79c17c92cbc870

- In pg_dump, split "dump" into "dump" and "dump_contains".
  Historically, the "dump" component of the namespace has been used to
  decide if the objects inside of the namespace should be dumped also.
  Given that "dump" is now a bitmask and may be partial, and we may
  want to dump out all components of the namespace object but only
  some of the components of objects contained in the namespace, create
  a "dump_contains" bitmask which will represent what components of
  the objects inside of a namespace should be dumped out.  No behavior
  change here, but in preparation for a change where we will dump out
  just the ACLs of objects in pg_catalog, but we might not dump out
  the ACL of the pg_catalog namespace itself (for instance, when it
  hasn't been changed from the value set at initdb time).  Reviews by
  Alexander Korotkov, Jose Luis Tallon
  http://git.postgresql.org/pg/commitdiff/d217b2c360cb9a746b4ef122c568bdfedb6d726e

- Bump catversion for pg_dump dump catalog ACL patches.  Pointed out
  by Tom.
  http://git.postgresql.org/pg/commitdiff/29dd1504a12f324c75f6b5ce8863505e499633ec

- Use GRANT system to manage access to sensitive functions.  Now that
  pg_dump will properly dump out any ACL changes made to functions
  which exist in pg_catalog, switch to using the GRANT system to
  manage access to those functions.  This means removing 'if
  (!superuser()) ereport()' checks from the functions themselves and
  then REVOKEing EXECUTE right from 'public' for these functions in
  system_views.sql.  Reviews by Alexander Korotkov, Jose Luis Tallon
  http://git.postgresql.org/pg/commitdiff/1574783b4ced0356fbc626af1a1a469faa6b41e1

- GRANT rights to CURRENT_USER instead of adding roles.  We shouldn't
  be adding roles during the regression tests as that can cause
  back-to-back installcheck runs to fail and users running the
  regression tests likley don't want those extra roles.  Pointed out
  by Tom
  http://git.postgresql.org/pg/commitdiff/6928484bda454f9ab2456d385b2d317f18b6bf1a

- In dumpTable, re-instate the skipping logic.  Pretty sure I removed
  this based on some incorrect thinking that it was no longer possible
  to reach this point for a table which will not be dumped, but that's
  clearly wrong.  Pointed out on IRC by Erik Rijkers.
  http://git.postgresql.org/pg/commitdiff/689f9a058854a1a32e994818dd6d79f49d8f8a1b

- Fix improper usage of 'dump' bitmap.  Now that 'dump' is a bitmap,
  we can't simply set it to 'true'.  Noticed while debugging the prior
  issue.
  http://git.postgresql.org/pg/commitdiff/fa6075e5515c6878b2c1fe1c6435dd7ed847857d

- Create default roles.  This creates an initial set of default roles
  which administrators may use to grant access to, historically,
  superuser-only functions.  Using these roles instead of granting
  superuser access reduces the number of superuser roles required for
  a system.  Documention for each of the default roles has been added
  to user-manag.sgml.  Bump catversion to 201604082, as we had a
  commit that bumped it to 201604081 and another that set it back to
  201604071...  Reviews by José Luis Tallón and Robert Haas
  http://git.postgresql.org/pg/commitdiff/7a542700df25eaf97b794bff63606176433dcdda

- Reserve the "pg_" namespace for roles.  This will prevent users from
  creating roles which begin with "pg_" and will check for those roles
  before allowing an upgrade using pg_upgrade.  This will allow for
  default roles to be provided at initdb time.  Reviews by José Luis
  Tallón and Robert Haas
  http://git.postgresql.org/pg/commitdiff/293007898d3fa5a815c1c5814df53627553f114d

Noah Misch pushed:

- Standardize GetTokenInformation() error reporting.  Commit
  c22650cd6450854e1a75064b698d7dcbb4a8821a sparked a discussion about
  diverse interpretations of "token user" in error messages.  Expel
  old and new specimens of that phrase by making all
  GetTokenInformation() callers report errors the way GetTokenUser()
  has been reporting them.  These error conditions almost can't
  happen, so users are unlikely to observe this change.  Reviewed by
  Tom Lane and Stephen Frost.
  http://git.postgresql.org/pg/commitdiff/f2b1b3079ce9d2965f6e450585f24d18cdf5647b

- Remove redundant message in AddUserToTokenDacl().  GetTokenUser()
  will have reported an adequate error message.  These error
  conditions almost can't happen, so users are unlikely to observe
  this change.  Reviewed by Tom Lane and Stephen Frost.
  http://git.postgresql.org/pg/commitdiff/33d3fc5e2aac32fcf356c09cee4bfded6613a1f3

Kevin Grittner pushed:

- Detect SSI conflicts before reporting constraint violations.  While
  prior to this patch the user-visible effect on the database of any
  set of successfully committed serializable transactions was always
  consistent with some one-at-a-time order of execution of those
  transactions, the presence of declarative constraints could allow
  errors to occur which were not possible in any such ordering, and
  developers had no good workarounds to prevent user-facing errors
  where they were not necessary or desired.  This patch adds a check
  for serialization failure ahead of duplicate key checking so that if
  a developer explicitly (redundantly) checks for the pre-existing
  value they will get the desired serialization failure where the
  problem is caused by a concurrent serializable transaction;
  otherwise they will get a duplicate key error.  While it would be
  better if the reads performed by the constraints could count as part
  of the work of the transaction for serialization failure checking,
  and we will hopefully get there some day, this patch allows a clean
  and reliable way for developers to work around the issue.  In many
  cases existing code will already be doing the right thing for this
  to "just work".  Author: Thomas Munro, with minor editing of docs by
  me Reviewed-by: Marko Tiikkaja, Kevin Grittner
  http://git.postgresql.org/pg/commitdiff/fcff8a575198478023ada8a48e13b50f70054766

- Modify BufferGetPage() to prepare for "snapshot too old" feature.
  This patch is a no-op patch which is intended to reduce the chances
  of failures of omission once the functional part of the "snapshot
  too old" patch goes in.  It adds parameters for snapshot, relation,
  and an enum to specify whether the snapshot age check needs to be
  done for the page at this point.  This initial patch passes NULL for
  the first two new parameters and BGP_NO_SNAPSHOT_TEST for the third.
  The follow-on patch will change the places where the test needs to
  be made.
  http://git.postgresql.org/pg/commitdiff/8b65cf4c5edabdcae45ceaef7b9ac236879aae50

- Add snapshot_too_old to NSVC @contrib_excludes.  The buildfarm
  showed failure for Windows MSVC builds due to this omission.  This
  might not be the only problem with the Makefile for this feature,
  but hopefully this will get it past the immediate problem.  Fix
  suggested by Tom Lane
  http://git.postgresql.org/pg/commitdiff/279d86afdbed550425bc9d1327ade2dc0028ad33

- Fix typo in C comment.
  http://git.postgresql.org/pg/commitdiff/381200be4b565292eba6f62200248cb775f06940

- Turn special page pointer validation to static inline function.
  Inclusion of multiple macros inside another macro was pushing MSVC
  past its size liimit.  Reported by buildfarm.
  http://git.postgresql.org/pg/commitdiff/56dffb5a73ab157fc8d35a76c1170d656a051f14

- Add the "snapshot too old" feature.  This feature is controlled by a
  new old_snapshot_threshold GUC.  A value of -1 disables the feature,
  and that is the default.  The value of 0 is just intended for
  testing.  Above that it is the number of minutes a snapshot can
  reach before pruning and vacuum are allowed to remove dead tuples
  which the snapshot would otherwise protect.  The xmin associated
  with a transaction ID does still protect dead tuples.  A connection
  which is using an "old" snapshot does not get an error unless it
  accesses a page modified recently enough that it might not be able
  to produce accurate results.  This is similar to the Oracle feature,
  and we use the same SQLSTATE and error message for compatibility.
  http://git.postgresql.org/pg/commitdiff/848ef42bb8c7909c9d7baa38178d4a209906e7c1

Andres Freund pushed:

- Increase maximum number of clog buffers.  Benchmarking has shown
  that the current number of clog buffers limits scalability. We've
  previously increased the number in 33aaa139, but that's not
  sufficient with a large number of clients.  We've benchmarked the
  cost of increasing the limit by benchmarking worst case scenarios;
  testing showed that 128 buffers don't cause a regression, even in
  contrived scenarios, whereas 256 does There are a number of more
  complex patches flying around to address various clog scalability
  problems, but this is simple enough that we can get it into 9.6; and
  is beneficial even after those patches have been applied.  It is a
  bit unsatisfactory to increase this in small steps every few
  releases, but a better solution seems to require a rewrite of
  slru.c; not something done quickly.  Author: Amit Kapila and Andres
  Freund Discussion:
  CAA4eK1+-=18HOrdqtLXqOMwZDbC_15WTyHiFruz7BvVArZPaAw@mail.gmail.com
  http://git.postgresql.org/pg/commitdiff/5364b357fb115ed4dc7174085d8f59d9425638dd

- Expose more out/readfuncs support functions.  Previously bcac23d
  exposed a subset of support functions, namely the ones Kaigai found
  useful. In 20160304193704.elq773pyg5fyl3mi@alap3.anarazel.de I
  mentioned that there's some functions missing to use the facility in
  an external project.  To avoid having to add functions piecemeal,
  add all the functions which are used to define READ_* and WRITE_*
  macros; users of the extensible node functionality are likely to
  need these. Additionally expose outDatum(), which doesn't have it's
  own WRITE_ macro, as it needs information from the embedding struct.
  Discussion: 20160304193704.elq773pyg5fyl3mi@alap3.anarazel.de
  http://git.postgresql.org/pg/commitdiff/c1ddd2361f6eb071d51b856c697a4aab22f8c776

- Avoid the use of a separate spinlock to protect a LWLock's wait
  queue.  Previously we used a spinlock, in adition to the atomically
  manipulated ->state field, to protect the wait queue. But it's
  pretty simple to instead perform the locking using a flag in state.
  Due to 6150a1b0 BufferDescs, on platforms (like PPC) with > 1 byte
  spinlocks, increased their size above 64byte. As 64 bytes are the
  size we pad allocated BufferDescs to, this can increase false
  sharing; causing performance problems in turn. Together with the
  previous commit this reduces the size to <= 64 bytes on all common
  platforms.  Author: Andres Freund Discussion:
  CAA4eK1+ZeB8PMwwktf+3bRS0Pt4Ux6Rs6Aom0uip8c6shJWmyg@mail.gmail.com
  20160327121858.zrmrjegmji2ymnvr@alap3.anarazel.de
  http://git.postgresql.org/pg/commitdiff/008608b9d51061b1f598c197477b3dc7be9c4a64

- Allow Pin/UnpinBuffer to operate in a lockfree manner.
  Pinning/Unpinning a buffer is a very frequent operation; especially
  in read-mostly cache resident workloads. Benchmarking shows that in
  various scenarios the spinlock protecting a buffer header's state
  becomes a significant bottleneck. The problem can be reproduced with
  pgbench -S on larger machines, but can be considerably worse for
  queries which touch the same buffers over and over at a high
  frequency (e.g. nested loops over a small inner table).  To allow
  atomic operations to be used, cram BufferDesc's flags, usage_count,
  buf_hdr_lock, refcount into a single 32bit atomic variable; that
  allows to manipulate them together using 32bit compare-and-swap
  operations. This requires reducing MAX_BACKENDS to 2^18-1 (which
  could be lifted by using a 64bit field, but it's not a realistic
  configuration atm).  As not all operations can easily implemented in
  a lockfree manner, implement the previous buf_hdr_lock via a flag
  bit in the atomic variable. That way we can continue to lock the
  header in places where it's needed, but can get away without
  acquiring it in the more frequent hot-paths.  There's some
  additional operations which can be done without the lock, but aren't
  in this patch; but the most important places are covered.  As
  bufmgr.c now essentially re-implements spinlocks, abstract the delay
  logic from s_lock.c into something more generic. It now has already
  two users, and more are coming up; there's a follupw patch for
  lwlock.c at least.  This patch is based on a proof-of-concept
  written by me, which Alexander Korotkov made into a fully working
  patch; the committed version is again revised by me.  Benchmarking
  and testing has, amongst others, been provided by Dilip Kumar,
  Alexander Korotkov, Robert Haas.  On a large x86 system improvements
  for readonly pgbench, with a high client count, of a factor of 8
  have been observed.  Author: Alexander Korotkov and Andres Freund
  Discussion: 2400449.GjM57CE0Yg@dinodell
  http://git.postgresql.org/pg/commitdiff/48354581a49c30f5757c203415aa8412d85b0f70


Andrew Dunstan pushed:

- Turn down MSVC compiler verbosity.  Most of what is produced by the
  detailed verbosity level is of no interest at all, so switch to the
  normal level for more usable output.  Christian Ullrich.  Backpatch
  to all live branches
  http://git.postgresql.org/pg/commitdiff/01a07e6c11562127ad5e6f58d3d6128416b8ab65

- Silence warning from modern perl about unescaped braces
  http://git.postgresql.org/pg/commitdiff/76a1c97bf21c301f61bb41345e0cdd0d365b2086

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Kyotaro HORIGUCHI sent in two more revisions of a patch to add tab
completion for IF [NOT] EXISTS to psql.

Emre Hasegeli sent in a patch to change "magick" to "magic."

Artur Zakirov sent in a patch to fix a typo in the documentation of
indexam.

Aleksander Alekseev sent in two revisions of a patch to fix an issue
in how sigmask works.

David Steele sent in two more revisions of a patch to filter messages
including errors that might expose information needlessly.

Fabrízio de Royes Mello sent in two more revisions of a patch to add a
sequence access method.

Amit Langote and Kyotaro HORIGUCHI traded patches to fix an issue
where altering a foreign table was failing to invalidate prepared
statement execution plan that depended on its previous state.

Robbie Harwood sent in another revision of a patch to implement GSSAPI
encryption.

Etsuro Fujita sent in another revision of a patch to handle odd
system-column handling in postgres_fdw join pushdown.

Etsuro Fujita and Rushabh Lathia traded patches to optimize writes to
the postgres fdw.

Rod Taylor sent in a patch to implement LOCK TABLE .. DEFERRABLE.

Craig Ringer sent in a patch to add some tests to pg_xlogdump.

Craig Ringer sent in a patch to fix incorrect comments introduced in
logical decoding timeline following.

Anastasia Lubennikova sent in five more revisions of a patch to add
covering unique indexes.

Pavel Stěhule sent in another revision of a patch to create a RAW
output format for COPY.

Aleksander Alekseev sent in a patch to simplify reorderbuffer.c

Simon Riggs sent in another revision of a patch to avoid archiving
XLOG_RUNNING_XACTS on idle server.

Muhammad Asif Naeem sent in a patch to add an EMERGENCY option to VACUUM
that forces to avoid extend any entries in the VM or FSM.

David Rowley and Tom Lane traded patches to improve performance of
outer joins when the outer side is unique.

Fabien COELHO sent in a patch to allow seeding randomness in pgbench.

WANGSHUO sent in a patch to allow UPDATE to operate on column aliases.

Michaël Paquier sent in another revision of a patch to add support for
VS 2015 in MSVC scripts.

Michaël Paquier sent in a patch to fix parallel pg_dump on Win32.

Aleksander Alekseev sent in a patch to fix an issue in snapmgr.c that
wrongly assumes that subxcnt > 0 iff xcnt > 0.

Anastasia Lubennikova sent in a patch to make the amcheck tool work
with covering unique indexes.

Constantin S. Pan sent in another revision of a patch to speed up GIN
index builds with parallel workers.

Stephen Frost sent in a patch to fix breakage of pg_dump caused by the
covering unique indexes patch.

Stephen Frost sent in a patch to remove superuser checks in
pgstattuple 1.4.

David Fetter sent in two more revisions of a patch to implement
weighted central moments as aggregates.

Stas Kelvich sent in another revision of a patch to speed up 2PC
transactions.

Jeff Janes sent in a patch to add tab completion for ALTER EXTENSION
to psql.

David Rowley sent in a patch to make parallel aggregate costs consider
combine/serial/deserial functions.

Stephen Frost sent in a patch to add regression tests for CREATE
ROLE/USAGE.

Andres Freund sent in a patch to disable pymalloc when running under
valgrind.