== PostgreSQL Weekly News - February 10, 2019 ==

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

== PostgreSQL Weekly News - February 10, 2019 ==

David Fetter
== PostgreSQL Weekly News - February 10, 2019 ==

== PostgreSQL Product News ==

barman 2.6, a backup and recovery manager for PostgreSQL, released.
https://www.pgbarman.org/barman-2-6-released/

== PostgreSQL Jobs for February ==

http://archives.postgresql.org/pgsql-jobs/2019-02/

== PostgreSQL Local ==

Prague PostgreSQL Developer Day 2019 (P2D2 2019) will be held on February 13-14,
2019 in Prague, Czech Republic.
http://www.p2d2.cz/

PGConf India 2019 will be on February 13-15, 2019 in Bengaluru, Karnataka.
http://pgconf.in/

PostgreSQL@SCaLE is a two day, two track event which takes place on
March 7-8, 2019, at Pasadena Convention Center, as part of SCaLE 17X.
https://www.socallinuxexpo.org/scale/17x/postgresscale

pgDay Paris 2019 will be held in Paris, France on March 12, 2019
at 199bis rue Saint-Martin.
http://2019.pgday.paris/

Nordic PGDay 2019 will be held in Copenhagen, Denmark, at the
Copenhagen Marriott Hotel, on March 19, 2019.
https://2019.nordicpgday.org/

PGConf APAC 2019 will be held in Singapore March 19-21, 2019.
http://2019.pgconfapac.org/

The German-speaking PostgreSQL Conference 2019 will take place on May 10, 2019
in Leipzig.  The CfP is open until February 26, 2019 at http://2019.pgconf.de/cfp
http://2019.pgconf.de/

PGDay.IT 2019 will take place May 16th and May 17th in Bologna, Italy.
https://2019.pgday.it/en/

PGCon 2019 will take place in Ottawa on May 28-31, 2019.
https://www.pgcon.org/2019

Swiss PGDay 2019 will take place in Rapperswil (near Zurich) on June 28, 2019.
The CfP is open through April 18, 2019, and registration is open.
http://www.pgday.ch/2019/

== 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 PST8PDT to [hidden email].

== Applied Patches ==

Michaël Paquier pushed:

- Clarify behavior of initdb's --allow-group-access on Windows in docs. The
  option is ignored on Windows, and GUC data_directory_mode already mentioned
  that within its description in the documentation.  Author: Michael Paquier
  Reported-by: Haribabu Kommi, David Steele Discussion:
  https://postgr.es/m/CAJrrPGefxTG43yk6BrOC7ZcMnCTccG9+inCSncvyys_t8Ev9cQ@...
  Backpatch-through: 11
  https://git.postgresql.org/pg/commitdiff/be12aa47e60c45f331e91693efdbc94497d4e9b0

- Tighten some regexes with proper character escaping in pg_dump TAP tests. Some
  tests have been using regular expressions which have been lax in escaping
  dots, which may cause tests to pass when they should not.  This make the whole
  set of tests more robust where needed.  Author: David Rowley Reviewed-by:
  Daniel Gustafsson, Michael Paquier Discussion:
  https://postgr.es/m/CAKJS1f9jD8aVo1BTH+Vgwd=f-ynbuRVrS90XbWMT6UigaOQJTA@...
  https://git.postgresql.org/pg/commitdiff/d07fb6810e51a676c4c631f673b8da09f63205b3

- Add more tests for CREATE TABLE AS with WITH NO DATA. The relation creation is
  done at executor startup, however the main regression test suite is lacking
  scenarios where no data is inserted which is something that can happen when
  using EXECUTE or EXPLAIN with CREATE TABLE AS and WITH NO DATA.  Some patches
  are worked on to reshape the way CTAS relations are created, so this makes
  sure that we do not miss some query patterns already supported.  Reported-by:
  Andreas Karlsson Author: Michael Paquier Reviewed-by: Andreas Karlsson
  Discussion: https://postgr.es/m/20190206091817.GB14980@...
  https://git.postgresql.org/pg/commitdiff/537898bd81bd8bd3650846e0abde4298ff1373da

- Align better test output regex with grammar in pg_dump TAP tests. This
  enforces one-or-more character matches in the regular expressions for pg_dump
  testing on SQL syntax output where zero-or-more matches implies a syntax
  error.  Author: Daniel Gustafsson Reviewed-by: David G. Johnston, Michael
  Paquier Discussion:
  https://postgr.es/m/B313C32C-0E24-4AFB-95FF-6DA0C4E18A89@...
  https://git.postgresql.org/pg/commitdiff/f339a998ffe6fb8aa8c114a33316e97b56cb1513

- Add pg_partition_root to display top-most parent of a partition tree. This is
  useful when looking at partition trees with multiple layers, and combined with
  pg_partition_tree, it provides the possibility to show up an entire tree by
  just knowing one member at any level.  Author: Michael Paquier Reviewed-by:
  Álvaro Herrera, Amit Langote Discussion:
  https://postgr.es/m/20181207014015.GP2407@...
  https://git.postgresql.org/pg/commitdiff/3677a0b26bb2f3f72d16dc7fa6f34c305badacce

Amit Kapila pushed:

- Avoid creation of the free space map for small heap relations, take 2.
  Previously, all heaps had FSMs. For very small tables, this means that the FSM
  took up more space than the heap did. This is wasteful, so now we refrain from
  creating the FSM for heaps with 4 pages or fewer. If the last known target
  block has insufficient space, we still try to insert into some other page
  before giving up and extending the relation, since doing otherwise leads to
  table bloat. Testing showed that trying every page penalized performance
  slightly, so we compromise and try every other page. This way, we visit at
  most two pages. Any pages with wasted free space become visible at next
  relation extension, so we still control table bloat. As a bonus, directly
  attempting one or two pages can even be faster than consulting the FSM would
  have been.  Once the FSM is created for a heap we don't remove it even if
  somebody deletes all the rows from the corresponding relation.  We don't think
  it is a useful optimization as it is quite likely that relation will again
  grow to the same size.  Author: John Naylor, Amit Kapila Reviewed-by: Amit
  Kapila Tested-by: Mithun C Y Discussion:
  https://www.postgresql.org/message-id/CAJVSVGWvB13PzpbLEecFuGFc5V2fsO736BsdTakPiPAcdMM5tQ@...
  https://git.postgresql.org/pg/commitdiff/b0eaa4c51bbff3e3c600b11e5d104d6feb9ca77f

- Make FSM test portable. In b0eaa4c51b, we allow FSM to be created only after 4
  pages.  One of the tests check the FSM contents and to do that it populates
  many tuples in the relation.  The FSM contents depend on the availability of
  freespace in the page and it could vary because of the alignment of tuples.
  This commit removes the dependency on FSM contents.  Author: Amit Kapila
  Discussion:
  https://postgr.es/m/CAA4eK1KADF6K1bagr0--mGv3dMcZ%3DH_Z-Qtvdfbp5PjaC6PJJA%40mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/08ecdfe7e5e0a31efbe1d58fefbe085b53bc79ca

- Doc: Update the documentation for row movement behavior across partitions. In
  commit f16241bef7c, we have changed the behavior for concurrent updates that
  move row to a different partition, but forgot to update the docs. Previously
  when an UPDATE command causes a row to move from one partition to another,
  there is a chance that another concurrent UPDATE or DELETE misses this row.
  However, now we raise a serialization failure error in such a case.
  Reported-by: David Rowley Author: David Rowley and Amit Kapila
  Backpatch-through: 11 where it was introduced Discussion:
  https://postgr.es/m/CAKJS1f-iVhGD4-givQWpSROaYvO3c730W8yoRMTF9Gc3craY3w@...
  https://git.postgresql.org/pg/commitdiff/793c736d69091d385a967b2740cc93cfb7a7b076

Andrew Gierth pushed:

- Move port-specific parts of with_temp_install to port makefile. Rather than
  define ld_library_path_ver with a big nested $(if), just put the overriding
  values in the makefiles for the relevant ports.  Also add a variable for port
  makefiles to append their own stuff to with_temp_install, and use it to set
  LD_LIBRARY_PATH_RPATH=1 on FreeBSD which is needed to make LD_LIBRARY_PATH
  override DT_RPATH if DT_RUNPATH is not set (which seems to depend in
  unpredictable ways on the choice of compiler, at least on my system).
  Backpatch for the benefit of anyone doing regression tests on FreeBSD. (For
  other platforms there should be no functional change.)
  https://git.postgresql.org/pg/commitdiff/54f5f887fd7df0ba9e286ce7bc4d1b1197afcbf3

Peter Eisentraut pushed:

- Remove unused macro. Use was removed in
  6d46f4783efe457f74816a75173eb23ed8930020 but definition was forgotten.
  https://git.postgresql.org/pg/commitdiff/f602cf49c2f614ef7450df30bab9df29842bd359

- Hide cascade messages in collate tests. These are not relevant to the tests
  and would just uselessly bloat patches.
  https://git.postgresql.org/pg/commitdiff/727921f466a5234e41b27d34f8e859ca39a93f9e

- Add collation assignment to CALL statement. Otherwise functions that require
  collation information will not have it if they are called in arguments to a
  CALL statement.  Reported-by: Jean-Marc Voillequin
  <[hidden email]> Reviewed-by: Tom Lane <[hidden email]>
  Discussion:
  https://www.postgresql.org/message-id/flat/1EC8157EB499BF459A516ADCF135ADCE39FFAC54%40LON-WGMSX712.ad.moodys.net
  https://git.postgresql.org/pg/commitdiff/cd5afd8175e256fa401cf440d06304df746abe62

- Allow some recovery parameters to be changed with reload. Change
  archive_cleanup_command promote_trigger_file recovery_end_command
  recovery_min_apply_delay  from PGC_POSTMASTER to PGC_SIGHUP.  This did not
  require any further changes.  Reviewed-by: Michael Paquier
  <[hidden email]> Discussion:
  https://www.postgresql.org/message-id/flat/ca28011a-cfaa-565c-d622-c1907c33ecf7%402ndquadrant.com
  https://git.postgresql.org/pg/commitdiff/13b89f96d07ad3da67b57f66c134c3609bd3e98f

- Use EXECUTE FUNCTION syntax for triggers more. Change pg_dump and ruleutils.c
  to use the FUNCTION keyword instead of PROCEDURE in trigger and event trigger
  definitions.  This completes the pieces of the transition started in
  0a63f996e018ac508c858e87fa39cc254a5db49f that were kept out of PostgreSQL 11
  because of the required catversion change.  Discussion:
  https://www.postgresql.org/message-id/381bef53-f7be-29c8-d977-948e389161d6@...
  https://git.postgresql.org/pg/commitdiff/0c1f8f166cb6273ab9c06a5f3c2ebedbf36f93e9

- Add some const decorations. These mainly help understanding the function
  signatures better.
  https://git.postgresql.org/pg/commitdiff/08d25d7850858094ed6aa7ccc2314f724242336d

- Fix error handling around ssl_*_protocol_version settings. In case of a
  reload, we just want to LOG errors instead of FATAL when processing SSL
  configuration, but the more recent code for the ssl_*_protocol_version
  settings didn't behave like that.  Author: Daniel Gustafsson <[hidden email]>
  Reviewed-by: Michael Paquier <[hidden email]>
  https://git.postgresql.org/pg/commitdiff/3d462f0861cd7ef8bca0bd186123869a08c89bc8

- Use better comment marker in Autoconf input. The comment marker "#" is copied
  to the output, so it's only appropriate for comments that make sense in the
  shell output.  For comments about the Autoconf language, "dnl" should be used.
  https://git.postgresql.org/pg/commitdiff/4446565d36ac4482282146a9ab35068f18dff4fd

Tom Lane pushed:

- Fix dumping of matviews with indirect dependencies on primary keys. Commit
  62215de29 turns out to have been not quite on-the-mark. When we are forced to
  postpone dumping of a materialized view into the dump's post-data section
  (because it depends on a unique index that isn't created till that section),
  we may also have to postpone dumping other matviews that depend on said
  matview.  The previous fix didn't reliably work for such cases: it'd break the
  dependency loops properly, producing a workable object ordering, but it didn't
  necessarily mark all the matviews as "postponed_def".  This led to harmless
  bleating about "archive items not in correct section order", as reported by
  Tom Cassidy in bug #15602.  Less harmlessly, selective-restore options such as
  --section might misbehave due to the matview dump objects not being properly
  labeled.  The right way to fix it is to consider that each pre-data dependency
  we break amounts to moving the no-longer-dependent object into post-data, and
  hence we should mark that object if it's a matview.  Back-patch to all
  supported versions, since the issue's been there since matviews were
  introduced.  Discussion:
  https://postgr.es/m/15602-e895445f73dc450b@...
  https://git.postgresql.org/pg/commitdiff/6e4d45b5f6babe48c066c547a7eedfc8152e5138

- Doc: in each release branch, keep only that branch's own release notes.
  Historically we've had each release branch include all prior branches' notes,
  including minor-release changes, back to the beginning of the project.  That's
  basically an O(N^2) proposition, and it was starting to catch up with us: as
  of HEAD the back-branch release notes alone accounted for nearly 30% of the
  documentation.  While there's certainly some value in easy access to
  back-branch notes, this is getting out of hand.  Hence, switch over to the
  rule that each branch contains only its own release notes.  So as to not make
  older notes too hard to find, each branch will provide URLs for the
  immediately preceding branches' release notes on the project website.  There
  might be value in providing aggregated notes across all branches somewhere on
  the website, but that's a task for another day.  Discussion:
  https://postgr.es/m/cbd4aeb5-2d9c-8b84-e968-9e09393d4c83@...
  https://git.postgresql.org/pg/commitdiff/527b5ed1ad469e19af458a3cbcc060899d1eab71

- Remove unnecessary "inline" marker introduced in commit 4be058fe9. Some of our
  older buildfarm members bleat about this coding, along the lines of
  prepjointree.c:112: warning: 'get_result_relid' declared inline after being
  called prepjointree.c:112: warning: previous declaration of 'get_result_relid'
  was here  Modern compilers will probably inline this function without being
  prompted, so rather than move the function, let's just drop the marking.
  https://git.postgresql.org/pg/commitdiff/24114e8b4df4a4ff2db9e608742768d219b1067c

- Update time zone data files to tzdata release 2018i. DST law changes in
  Kazakhstan, Metlakatla, and São Tomé and Príncipe. Kazakhstan's Qyzylorda zone
  is split in two, creating a new zone Asia/Qostanay, as some areas did not
  change UTC offset. Historical corrections for Hong Kong and numerous Pacific
  islands.
  https://git.postgresql.org/pg/commitdiff/d63dc0aa0ccf432f3bc9a735e77eb3845732cf28

- Propagate lateral-reference information to indirect descendant relations.
  create_lateral_join_info() computes a bunch of information about lateral
  references between base relations, and then attempts to propagate those
  markings to appendrel children of the original base relations.  But the
  original coding neglected the possibility of indirect descendants
  (grandchildren etc).  During v11 development we noticed that this was wrong
  for partitioned-table cases, but failed to realize that it was just as wrong
  for any appendrel.  While the case can't arise for appendrels derived from
  traditional table inheritance (because we make a flat appendrel for that),
  nested appendrels can arise from nested UNION ALL subqueries.  Failure to mark
  the lower-level relations as having lateral references leads to confusion in
  add_paths_to_append_rel about whether unparameterized paths can be built.
  It's not very clear whether that leads to any user-visible misbehavior; the
  lack of field reports suggests that it may cause nothing worse than minor cost
  misestimation.  Still, it's a bug, and it leads to failures of Asserts that I
  intend to add later.  To fix, we need to propagate information from all
  appendrel parents, not just those that are RELOPT_BASERELs.  We can still do
  it in one pass, if we rely on the append_rel_list to be ordered with ancestor
  relationships before descendant ones; add assertions checking that. While
  fixing this, we can make a small performance improvement by traversing the
  append_rel_list just once instead of separately for each appendrel parent
  relation.  Noted while investigating bug #15613, though this patch does not
  fix that (which is why I'm not committing the related Asserts yet).
  Discussion: https://postgr.es/m/3951.1549403812@...
  https://git.postgresql.org/pg/commitdiff/bdd9a99aac3bb0eaa49b5db81b2bd9402617fa32

- Split create_foreignscan_path() into three functions. Up to now postgres_fdw
  has been using create_foreignscan_path() to generate not only base-relation
  paths, but also paths for foreign joins and foreign upperrels.  This is wrong,
  because create_foreignscan_path() calls get_baserel_parampathinfo() which will
  only do the right thing for baserels.  It accidentally fails to fail for
  unparameterized paths, which are the only ones postgres_fdw (thought it) was
  handling, but we really need different APIs for the baserel and join cases.
  In HEAD, the best thing to do seems to be to split up the baserel, joinrel,
  and upperrel cases into three functions so that they can have different APIs.
  I haven't actually given create_foreign_join_path a different API in this
  commit: we should spend a bit of time thinking about just what we want to do
  there, since perhaps FDWs would want to do something different from the
  build-up-a-join-pairwise approach that get_joinrel_parampathinfo expects.  In
  the meantime, since postgres_fdw isn't prepared to generate parameterized
  joins anyway, just give it a defense against trying to plan joins with lateral
  refs.  In addition (and this is what triggered this whole mess) fix bug #15613
  from Srinivasan S A, by teaching file_fdw and postgres_fdw that plain baserel
  foreign paths still have outer refs if the relation has lateral_relids.  Add
  some assertions in relnode.c to catch future occurrences of the same error ---
  in particular, to catch other FDWs doing that, but also as backstop against
  core-code mistakes like the one fixed by commit bdd9a99aa.  Bug #15613 also
  needs to be fixed in the back branches, but the appropriate fix will look
  quite a bit different there, since we don't want to assume that existing FDWs
  get the word right away.  Discussion:
  https://postgr.es/m/15613-092be1be9576c728@...
  https://git.postgresql.org/pg/commitdiff/34ea1ab7fd305afe1124a6e73ada0ebae04b6ebb

- Doc: fix thinko in description of how to escape a backslash in bytea. Also
  clean up some discussion that had been left in a very confused state thanks to
  half-hearted adjustments for the change to standard_conforming_strings being
  the default.  Discussion:
  https://postgr.es/m/154954987367.1297.4358910045409218@...
  https://git.postgresql.org/pg/commitdiff/f10a20e14714d2b06b84a260a2bf6cef55f46801

- Defend against null error message reported by libxml2. While this isn't really
  supposed to happen, it can occur in OOM situations and perhaps others.
  Instead of crashing, substitute "(no message provided)".  I didn't worry about
  localizing this text, since we aren't localizing anything else here; besides,
  if we're on the edge of OOM, it's unlikely gettext() would work.  Report and
  fix by Sergio Conde Gómez in bug #15624.  Discussion:
  https://postgr.es/m/15624-4dea54091a2864e6@...
  https://git.postgresql.org/pg/commitdiff/0edef16d76beb8286cc832e4e1daf1f16b3d8f4a

- Call set_rel_pathlist_hook before generate_gather_paths, not after. The
  previous ordering of these steps satisfied the nominal requirement that
  set_rel_pathlist_hook could editorialize on the whole set of Paths constructed
  for a base relation.  In practice, though, trying to change the set of partial
  paths was impossible.  Adding one didn't work because (a) it was too late to
  be included in Gather paths made by the core code, and (b) calling
  add_partial_path after generate_gather_paths is unsafe, because it might try
  to delete a path it thinks is dominated, but that is already embedded in some
  Gather path(s).  Nor could the hook safely remove partial paths, for the same
  reason that they might already be embedded in Gathers.  Better to call
  extensions first, let them add partial paths as desired, and then gather.  In
  v11 and up, we already doubled down on that ordering by postponing gathering
  even further for single-relation queries; so even if the hook wished to
  editorialize on Gather path construction, it could not.  Report and patch by
  KaiGai Kohei.  Back-patch to 9.6 where Gather paths were added.  Discussion:
  https://postgr.es/m/CAOP8fzahwpKJRTVVTqo2AE=mDTz_efVzV6Get_0=U3SO+-ha1A@...
  https://git.postgresql.org/pg/commitdiff/6401583863eaf83624994908911350b03f9978ae

- Refactor the representation of indexable clauses in IndexPaths. In place of
  three separate but interrelated lists (indexclauses, indexquals, and
  indexqualcols), an IndexPath now has one list "indexclauses" of IndexClause
  nodes.  This holds basically the same information as before, but in a more
  useful format: in particular, there is now a clear connection between an
  indexclause (an original restriction clause from WHERE or JOIN/ON) and the
  indexquals (directly usable index conditions) derived from it.  We also change
  the ground rules a bit by mandating that clause commutation, if needed, be
  done up-front so that what is stored in the indexquals list is always directly
  usable as an index condition.  This gets rid of repeated re-determination of
  which side of the clause is the indexkey during costing and plan generation,
  as well as repeated lookups of the commutator operator.  To minimize the added
  up-front cost, the typical case of commuting a plain OpExpr is handled by a
  new special-purpose function commute_restrictinfo().  For RowCompareExprs,
  generating the new clause properly commuted to begin with is not really any
  more complex than before, it's just different --- and we can save doing that
  work twice, as the pretty-klugy original implementation did.  Tracking the
  connection between original and derived clauses lets us also track explicitly
  whether the derived clauses are an exact or lossy translation of the original.
  This provides a cheap solution to getting rid of unnecessary rechecks of
  boolean index clauses, which previously seemed like it'd be more expensive
  than it was worth.  Another pleasant (IMO) side-effect is that EXPLAIN now
  always shows index clauses with the indexkey on the left; this seems less
  confusing.  This commit leaves expand_indexqual_conditions() and some related
  functions in a slightly messy state.  I didn't bother to change them any more
  than minimally necessary to work with the new data structure, because all that
  code is going to be refactored out of existence in a follow-on patch.
  Discussion: https://postgr.es/m/22182.1549124950@...
  https://git.postgresql.org/pg/commitdiff/1a8d5afb0dfc5d0dcc6eda0656a34cb1f0cf0bdf

- Create the infrastructure for planner support functions. Rename/repurpose
  pg_proc.protransform as "prosupport".  The idea is still that it names an
  internal function that provides knowledge to the planner about the behavior of
  the function it's attached to; but redesign the API specification so that it's
  not limited to doing just one thing, but can support an extensible set of
  requests.  The original purpose of simplifying a function call is handled by
  the first request type to be invented, SupportRequestSimplify. Adjust all the
  existing transform functions to handle this API, and rename them fron
  "xxx_transform" to "xxx_support" to reflect the potential generalization of
  what they do.  (Since we never previously provided any way for extensions to
  add transform functions, this change doesn't create an API break for them.)
  Also add DDL and pg_dump support for attaching a support function to a
  user-defined function.  Unfortunately, DDL access has to be restricted to
  superusers, at least for now; but seeing that support functions will pretty
  much have to be written in C, that limitation is just theoretical.  (This
  support is untested in this patch, but a follow-on patch will add cases that
  exercise it.)  Discussion: https://postgr.es/m/15193.1548028093@...
  https://git.postgresql.org/pg/commitdiff/1fb57af92069ee104c09e2016af9e0e620681be3

- Build out the planner support function infrastructure. Add support function
  requests for estimating the selectivity, cost, and number of result rows (if a
  SRF) of the target function.  The lack of a way to estimate selectivity of a
  boolean-returning function in WHERE has been a recognized deficiency of the
  planner since Berkeley days.  This commit finally fixes it.  In addition,
  non-constant estimates of cost and number of output rows are now possible.  We
  still fall back to looking at procost and prorows if the support function
  doesn't service the request, of course.  To make concrete use of the
  possibility of estimating output rowcount for SRFs, this commit adds support
  functions for array_unnest(anyarray) and the integer variants of
  generate_series; the lack of plausible rowcount estimates for those, even when
  it's obvious to a human, has been a repeated subject of complaints.
  Obviously, much more could now be done in this line, but I'm mostly just
  trying to get the infrastructure in place.  Discussion:
  https://postgr.es/m/15193.1548028093@...
  https://git.postgresql.org/pg/commitdiff/a391ff3c3d418e404a2c6e4ff0865a107752827b

- Repair unsafe/unportable snprintf usage in pg_restore. warn_or_exit_horribly()
  was blithely passing a potentially-NULL string pointer to a %s format
  specifier.  That works (at least to the extent of not crashing) on some
  platforms, but not all, and since we switched to our own snprintf.c it doesn't
  work for us anywhere.  Of the three string fields being handled this way here,
  I think that only "owner" is supposed to be nullable ... but considering that
  this is error-reporting code, it has very little business assuming anything,
  so put in defenses for all three.  Per a crash observed on buildfarm member
  crake and then reproduced here.  Because of the portability aspect, back-patch
  to all supported versions.
  https://git.postgresql.org/pg/commitdiff/4dbe1969079672064777e71c3fc981abbf55e207

- Solve cross-version-upgrade testing problem induced by 1fb57af92. Renaming
  varchar_transform to varchar_support had a side effect I hadn't foreseen: the
  core regression tests leave around a transform object that relies on that
  function, so the name change breaks cross-version upgrade tests, because the
  name used in the older branches doesn't match.  Since the dependency on
  varchar_transform was chosen with the aid of a dartboard anyway (it would
  surely not work as a language transform support function), fix by just
  choosing a different random builtin function with the right signature. Also
  add some comments explaining why this isn't horribly unsafe.  I chose to make
  the same substitution in a couple of other copied-and-pasted test cases, for
  consistency, though those aren't directly contributing to the testing problem.
  Per buildfarm.  Back-patch, else it doesn't fix the problem.
  https://git.postgresql.org/pg/commitdiff/068503c76511cdb0080bab689662a20e86b9c845

- Add per-test-script runtime display to pg_regress.  It seems useful to have
  this information available, so that it's easier to tell when a test script is
  taking a disproportionate amount of time.  Discussion:
  https://postgr.es/m/16646.1549770618@...
  https://git.postgresql.org/pg/commitdiff/72d71e03563b6c295b257040e324793a30162042

Andrew Dunstan pushed:

- Fix searchpath for modern Perl for genbki.pl. This was fixed for MSVC tools by
  commit 1df92eeafefac4, but per buildfarm member bowerbird genbki.pl needs the
  same treatment.  Backpatch to all live branches.
  https://git.postgresql.org/pg/commitdiff/f884a96819ad375a3220fffadcd47d0dcabeece4

- Keep perl style checker happy. It doesn't like code before "use strict;".
  https://git.postgresql.org/pg/commitdiff/8916b33e52485f0acea98fdfc919c2313178f865

- Fix included file path for modern perl. Contrary to the comment on 772d4b76,
  only paths starting with "./" or "../" are considered relative to the current
  working directory by perl's "do" function. So this patch converts all the
  relevant cases to use "./" paths. This only affects MSVC.  Backpatch to all
  live branches.
  https://git.postgresql.org/pg/commitdiff/f83419b7396fe5c64613838fd9eab8424591ad4a

- Unify searchpath and do file logic in MSVC build scripts. Commit f83419b739
  failed to notice that mkvcbuild.pl and build.pl use different searchpath and
  do-file logic, breaking the latter, so it is adjusted to use the same logic as
  mkvcbuild.pl.
  https://git.postgresql.org/pg/commitdiff/592123efbb60443d717ab8da9c6735aaec88ac44

- Fix searchpath and module location for pg_rewind and ssl TAP tests. The
  modules RewindTest.pm and ServerSetup.pm are really only useful for TAP tests,
  so they really belong in the TAP test directories. In addition, ServerSetup.pm
  is renamed to SSLServer.pm.  The test scripts have their own directories added
  to the search path so that the relocated modules will be found, regardless of
  where the tests are run from, even on modern perl where "." is no longer in
  the searchpath.  Discussion:
  https://postgr.es/m/e4b0f366-269c-73c3-9c90-d9cb0f4db1f9@...
  Backpatch as appropriate to 9.5
  https://git.postgresql.org/pg/commitdiff/8ce641f99709669133c6cbb12aa3d516af7897aa

- Fix perl searchpath for gen_keywordlist.pl. as found by running
  src/tools/perlcheck/pgperlsyncheck
  https://git.postgresql.org/pg/commitdiff/51b025933d442823b076e36f4dbe756d25b1a159

Andres Freund pushed:

- Fix heap_getattr() handling of fast defaults. Previously heap_getattr()
  returned NULL for attributes with a fast default value (c.f. 16828d5c0273), as
  it had no handling whatsoever for that case.  A previous fix, 7636e5c60f,
  attempted to fix issues caused by this oversight, but just expanding OLD
  tuples for triggers doesn't actually solve the underlying issue.  One known
  consequence of this bug is that the check for HOT updates can return the wrong
  result, when a previously fast-default'ed column is set to NULL. Which in turn
  means that an index over a column with fast default'ed columns might be
  corrupt if the underlying column(s) allow NULLs.  Fix by handling fast default
  columns in heap_getattr(), remove now superfluous expansion in
  GetTupleForTrigger().  Author: Andres Freund Discussion:
  https://postgr.es/m/20190201162404.onngi77f26baem4g@...
  Backpatch: 11, where fast defaults were introduced
  https://git.postgresql.org/pg/commitdiff/171e0418b03dc103d5d9bdc0bfaadbb193dd7fd6

- Plug leak in BuildTupleHashTable by creating ExprContext in correct context.
  In bf6c614a2f2c5 I added a expr context to evaluate the grouping expression.
  Unfortunately the code I added initialized them while in the calling context,
  rather the table context.  Additionally, I used CreateExprContext() rather
  than CreateStandaloneExprContext(), which creates the econtext in the estate's
  query context.  Fix that by using CreateStandaloneExprContext when in the
  table's tablecxt. As we rely on the memory being freed by a memory context
  reset that means that the econtext's shutdown callbacks aren't being called,
  but that seems ok as the expressions are tightly controlled due to
  ExecBuildGroupingEqual().  Bug: #15592 Reported-By: Dmitry Marakasov Author:
  Andres Freund Discussion:
  https://postgr.es/m/20190114222838.h6r3fuyxjxkykf6t@...
  Backpatch: 11, where I broke this in bf6c614a2f2c5
  https://git.postgresql.org/pg/commitdiff/5567d12ce030781a4f749c9cd2034b95a3b64424

- simplehash: Add support for resetting a hashtable's contents. A hashtable
  reset just reset the hashtable entries, but does not free memory.  Author:
  Andres Freund Discussion:
  https://postgr.es/m/20190114180423.ywhdg2iagzvh43we@... Bug:
  #15592 #15486 Backpatch: 11, this is a prerequisite for other fixes
  https://git.postgresql.org/pg/commitdiff/3b632a58e7985c6589dbd0e6c0f32ba007783cfa

- Allow to reset execGrouping.c style tuple hashtables. This has the advantage
  that the comparator expression, the table's slot, etc do not have to be
  rebuilt. Additionally the simplehash.h hashtable within the tuple hashtable
  now keeps its previous size and doesn't need to be reallocated. That both
  reduces allocator overhead, and improves performance in cases where the input
  estimation was off by a significant factor.  To avoid an API/ABI break, the
  new parameter is exposed via the new BuildTupleHashTableExt(), and
  BuildTupleHashTable() now is a wrapper around the former, that continues to
  allocate the table itself in the tablecxt.  Using this fixes performance
  issues discovered in the two bugs referenced. This commit however has not
  converted the callers, that's done in a separate commit.  Bug: #15592 #15486
  Reported-By: Jakub Janeček, Dmitry Marakasov Author: Andres Freund Discussion:
  https://postgr.es/m/15486-05850f065da42931@...
  https://postgr.es/m/20190114180423.ywhdg2iagzvh43we@...
  Backpatch: 11, this is a prerequisite for other fixes
  https://git.postgresql.org/pg/commitdiff/317ffdfeaac12e434b2befa24993dc1b52a140fd

- Reset, not recreate, execGrouping.c style hashtables. This uses the facility
  added in the preceding commit to fix performance issues caused by rebuilding
  the hashtable (with its comparator expression being the most expensive bit),
  after every reset. That's especially important when the comparator is JIT
  compiled.  Bug: #15592 #15486 Reported-By: Jakub Janeček, Dmitry Marakasov
  Author: Andres Freund Discussion:
  https://postgr.es/m/15486-05850f065da42931@...
  https://postgr.es/m/20190114180423.ywhdg2iagzvh43we@...
  Backpatch: 11, where I broke this in bf6c614a2f2c5
  https://git.postgresql.org/pg/commitdiff/356687bd825e5ca7230d43c1bffe7a59ad2e77bd

Peter Geoghegan pushed:

- Avoid amcheck inline compression false positives. The previous tacit
  assumption that index_form_tuple() hides differences in the TOAST state of its
  input datums was wrong.  Normalize input varlena datums by decompressing
  compressed values, and forming a new index tuple for fingerprinting using
  uncompressed inputs.  The final normalized representation may actually be
  compressed once again within index_form_tuple(), though that shouldn't matter.
  When the original tuple is found to have no datums that are compressed inline,
  fingerprint the original tuple directly.  Normalization avoids false positive
  reports of corruption in certain cases.  For example, the executor can apply
  toasting with some inline compression to an entire heap tuple because its
  input has a single external TOAST pointer.  Varlena datums for other
  attributes that are not particularly good candidates for inline compression
  can be compressed in the heap tuple in passing, without the representation of
  the same values in index tuples ever receiving concomitant inline compression.
  Add a test case to recreate the issue in a simpler though less realistic way:
  by exploiting differences in pg_attribute.attstorage between heap and index
  relations.  This bug was discovered by me during testing of an upcoming set of
  nbtree enhancements.  It was also independently reported by Andreas Kunert, as
  bug #15597.  His test case was rather more realistic than the one I ended up
  using.  Bug: #15597 Discussion:
  https://postgr.es/m/CAH2-WznrVd9ie+TTJ45nDT+v2nUt6YJwQrT9SebCdQKtAvfPZw@...
  Discussion: https://postgr.es/m/15597-294e5d3e7f01c407@...
  Backpatch: 11-, where heapallindexed verification was introduced.
  https://git.postgresql.org/pg/commitdiff/eba775345d23d2c999bbb412ae658b6dab36e3e8

Álvaro Herrera pushed:

- Fix trigger drop procedure. After commit 123cc697a8eb, we remove redundant FK
  action triggers during partition ATTACH by merely deleting the catalog tuple,
  but that's wrong: it should use performDeletion() instead.  Repair, and make
  the comments more explicit.  Per code review from Tom Lane.  Discussion:
  https://postgr.es/m/18885.1549642539@...
  https://git.postgresql.org/pg/commitdiff/cb90de1aac18f8d9d89af8a3c2286aa0691c8214

== Pending Patches ==

Masahiko Sawada sent in another revision of a patch to add a
--disable-index-cleanup option to VACUUM and vacuumdb.

Tom Lane sent in a patch to enable extensions to supply
operator-/function-specific info.

Haribabu Kommi sent in a patch to recommend that log_file_mode be 0640 for
group-readable directories to allow reading of log files by the members of the
same group.

Kuroda Hayato sent in another revision of a patch to add DECLARE STATEMENT to
ECPG.

Amul Sul sent in another revision of a patch to improve the partition-wise
joining mechanism.

Edmund Horner sent in another revision of a patch to add a selectivity estimate
for CTID system variables, support backward scans over restricted ranges in heap
access methods, and support range quals in TID scans.

Lætitia Avrot sent in another revision of a patch to implement log10 and
hyperbolic functions.

Thomas Munro sent in another revision of a patch to add a synchronous replay
mode for avoiding stale reads on hot standbys.

Surafel Temesgen sent in another revision of a patch to add --rows-per-insert to
pg_dump.

David Rowley sent in another revision of a patch to add basic support for using
the POPCNT and SSE4.2s LZCNT opcodes.

Surafel Temesgen sent in another revision of a patch to implement FETCH FIRST
... WITH TIES.

Andrew Gierth sent in another revision of a patch to replace strotod with
strotof as infrastructure for the Ryu patch.

Pavel Stěhule sent in another revision of a patch to implement pragmas in
PL/pgsql.

Michael Banck sent in another revision of a patch to enable verifying checksums
on line.

Peter Eisentraut sent in a patch to Use EXECUTE FUNCTION syntax for triggers
more pervasively.

David Rowley sent in two revisions of a patch to tighten up a few overly lax
regexes in pg_dump's tap tests.

Haribabu Kommi sent in another revision of a patch to document the new pluggable
storage APIs.

Álvaro Herrera sent in three more revisions of a patch to propagate REPLICA
IDENTITY to partitions.

David Rowley sent in another revision of a patch to forgo generating
single-subpath Append and MergeAppend paths.

Antonin Houska sent in another revision of a patch to push down aggregates.

David Rowley sent in another revision of a patch to fix a performance issue in
foreign-key-aware join estimation.

Jerry Jelinek sent in another revision of a patch to allow disable of WAL
recycling.

Álvaro Herrera sent in another revision of a patch to call out unsuitable
relkinds.

Andrey V. Lepikhov sent in another revision of a patch to reduce the amount of
WAL generated by CREATE INDEX for GiST, GIN and SP-GiST.

Peter Eisentraut sent in a patch to fix the optimization of foreign-key on
update actions.

Kyotaro HORIGUCHI sent in a patch to fix a bug which manifests as an internal
error while setting reloption on system catalogs.

David Rowley and Amit Kapila traded patches to document the fact that UPDATEs
which can move a tuple from one partition to another "just work."

John Naylor sent in another revision of a patch to improve the FSM regression
test.

David Rowley sent in another revision of a patch to fix inadequate executor
locking of indexes.

Pavan Deolasee sent in a patch to add a separate table level option to control
compression.

Marius Timmer sent in another revision of a patch to implement
clientcert=verify-full.

Peter Eisentraut sent in another revision of a patch to implement collations
with nondeterministic comparison.

Robert Haas sent in a patch to fix a failure of dsa_allocate().

Michaël Paquier sent in a patch to ensure that CTAS works in the WITH NO DATA
case.

Andreas Karlsson sent in two revisions of a patch to add CINE support to CREATE
TABLE AS EXECUTE.

Arseny Sher sent in a patch to remove the assertion in reorderbuffer that cmax
is stable.

Amit Khandekar sent in two revisions of a patch to pre-fetch the buffers keeping
a constant distance ahead of the buffer reads.

Amit Langote, Imai Yoshikazu, and Takayuki Tsunakawa traded patches to speed up
planning with partitions.

Kyotaro HORIGUCHI and Tomáš Vondra traded patches to remove catcache entries
that haven't been used for a certain time, track syscache usage, and add a
prune-number-of-entries feature.

Peter Eisentraut sent in a patch to make more use of unconstify() by replacing
casts whose only purpose is to cast away const.

Michaël Paquier sent in another revision of a patch to add a max_wal_senders
GUC.

Peter Eisentraut sent in another revision of a patch to implement REINDEX
CONCURRENTLY.

John Naylor sent in two revisions of a patch to use Getopt::Long in catalog
scripts.

Antonin Houska sent in another revision of a patch to fix some problems with
plan estimates in the PostgreSQL FDW.

Tomáš Vondra sent in three revisions of a patch to fix a performance issue in
remove_from_unowned_list().

Kyotaro HORIGUCHI sent in two revisions of a patch to explicitly mark some
attributes in the catalog as not needing a toast relation.

Noah Misch sent in another revision of a patch to synchronize with the upstream
imath library.

Peter Eisentraut sent in a patch to set the fallback_application_name for a
walreceiver to cluster_name.

Pavel Stěhule sent in another revision of a patch to implement \dP (partitions)
in psql.

Ryo Matsumura sent in another revision of a patch to add a 'bytea' type to ECPG.

Antonin Houska sent in a patch to fix a situation where an incorrect visibility
test function was being assigned to snapshot.

Sergey Cherkashin sent in another revision of a patch to add a client connection
check during the execution of the query.

Ashutosh Sharma sent in two revisions of a patch to make it possible to create a
view on a table without columns.

Brandur Leach sent in two revisions of a patch to create a SortSupport
implementation for inet/cidr.

Aleksey Kondratov sent in another revision of a patch to pg_rewind which makes
it possible to use restore_command from postgresql.conf or the command line.

Tom Lane sent in two revisions of a patch to remove findDependentObjects()'s
dependency on scan order.

Álvaro Herrera sent in two revisions of a patch to fix trigger dropping.

Haribabu Kommi sent in a patch to avoid counting parallel worker transactions
stats.

Hironobu SUZUKI sent in another revision of a patch to pgbench to add a
pseudo-random permutation function.