Обсуждение: == PostgreSQL Weekly News - September 9, 2018 ==

Поиск
Список
Период
Сортировка

== PostgreSQL Weekly News - September 9, 2018 ==

От
David Fetter
Дата:
== PostgreSQL Weekly News - September 9, 2018 ==

PGDay Down Under 2018 will be held on December 7, 2018 in Melbourne,
Australia. The CfP is open until 5pm AEST on September 30, 2018.
https://pgdu.org/

== PostgreSQL Product News ==

repmgr 4.1.1, a replication manager for PostgreSQL, released.
https://repmgr.org/docs/4.1/release-4.1.1.html

pgAdmin4 3.3, a web- and native GUI control center for PostgreSQL, released.
https://www.pgadmin.org/docs/pgadmin4/dev/release_notes_3_3.html

temboard 2.0, a management tool for PostgreSQL, released.
https://dali.bo/temboard-2-0-EN

== PostgreSQL Local ==

The Portland PostgreSQL Users Group will be holding a PGDay on September 10,
2018 in Portland, OR.
https://pdx.postgresql.us/pdxpgday2018

PostgresConf South Africa 2018 will take place in Johannesburg on October 9, 2018
https://postgresconf.org/conferences/SouthAfrica2018

PostgreSQL Conference Europe 2018 will be held on October 23-26, 2018 at the
Lisbon Marriott Hotel in Lisbon, Portugal.
https://2017.pgconf.eu/

2Q PGConf will be on December 4-5, 2018 in Chicago, IL.
http://www.2qpgconf.com/

PGConf.ASIA 2018 will take place on December 10-12, 2018 in Akihabara, Tokyo,
Japan.
http://www.pgconf.asia/EN/2018/

== 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 david@fetter.org.

== Applied Patches ==

Tomáš Vondra:

- Fix memory leak in TRUNCATE decoding.  When decoding a TRUNCATE record, the
  relids array was being allocated in the main ReorderBuffer memory context, but
  not released with the change resulting in a memory leak.  The array was also
  ignored when serializing/deserializing the change, assuming all the
  information is stored in the change itself.  So when spilling the change to
  disk, we've only we have serialized only the pointer to the relids array.
  Thanks to never releasing the array, the pointer however remained valid even
  after loading the change back to memory, preventing an actual crash.  This
  fixes both the memory leak and (de)serialization.  The relids array is still
  allocated in the main ReorderBuffer memory context (none of the existing ones
  seems like a good match, and adding an extra context seems like an overkill).
  The allocation is wrapped in a new ReorderBuffer API functions, to keep the
  details within reorderbuffer.c, just like the other ReorderBufferGet methods
  do.  Author: Tomas Vondra Discussion:
  https://www.postgresql.org/message-id/flat/66175a41-9342-2845-652f-1bd4c3ee50aa%402ndquadrant.com
  Backpatch: 11, where decoding of TRUNCATE was introduced
  https://git.postgresql.org/pg/commitdiff/4ddd8f5f55a0a1967fc787e42182745ca1e3a995

Álvaro Herrera pushed:

- Remove pg_constraint.conincluding.  This column was added in commit
  8224de4f42cc ("Indexes with INCLUDE columns and their support in B-tree") to
  ease writing the ruleutils.c supporting code for that feature, but it turns
  out to be unnecessary -- we can do the same thing with just one more syscache
  lookup.  Even the documentation for the new column being removed in this
  commit is awkward.  Discussion:
  https://postgr.es/m/20180902165018.33otxftp3olgtu4t@alvherre.pgsql
  https://git.postgresql.org/pg/commitdiff/c076f3d74af6e4836206142446bdcc2f93e149d6

- Simplify partitioned table creation vs. relcache.  In the original code, we
  were storing the pg_inherits row for a partitioned table too early: enough
  that we had a hack for relcache to avoid falling flat on its face while
  reading such a partial entry.  If we finish the pg_class creation first and
  *then* store the pg_inherits entry, we don't need that hack.  Also recognize
  that pg_class.relpartbound is not marked NOT NULL and therefore it's entirely
  possible to read null values, so having only Assert() protection isn't enough.
  Change those to if/elog tests instead.  This qualifies as a robustness fix, so
  backpatch to pg11.  In passing, remove one access that wasn't actually needed,
  and reword one message to be like all the others that check for the same
  thing.  Reviewed-by: Amit Langote Discussion:
  https://postgr.es/m/20180903213916.hh6wasnrdg6xv2ud@alvherre.pgsql
  https://git.postgresql.org/pg/commitdiff/2fbdf1b38bc54b297e0f885ca97e0c8f5c922e72

Amit Kapila pushed:

- During the split, set checksum on an empty hash index page.  On a split, we
  allocate a new splitpoint's worth of bucket pages wherein we initialize the
  last page with zeros which is fine, but we forgot to set the checksum for that
  last page.  We decided to back-patch this fix till 10 because we don't have an
  easy way to test it in prior versions.  Another reason is that the hash-index
  code is changed heavily in 10, so it is not advisable to push the fix without
  testing it in prior versions.  Author: Amit Kapila Reviewed-by: Yugo Nagata
  Backpatch-through: 10 Discussion:
  https://postgr.es/m/5d03686d-727c-dbf8-0064-bf8b97ffe850@2ndquadrant.com
  https://git.postgresql.org/pg/commitdiff/7c9e19ca9a4de6eb98582548ec6dd0d83fc5ac2d

- Prohibit pushing subqueries containing window function calculation to.
  workers.  Allowing window function calculation in workers leads to
  inconsistent results because if the input row ordering is not fully
  deterministic, the output of window functions might vary across workers.  The
  fix is to treat them as parallel-restricted.  In the passing, improve the
  coding pattern in max_parallel_hazard_walker so that it has a chain of
  mutually-exclusive if ... else if ... else if ... else if ... IsA tests.
  Reported-by: Marko Tiikkaja Bug: 15324 Author: Amit Kapila Reviewed-by: Tom
  Lane Backpatch-through: 9.6 Discussion:
  https://postgr.es/m/CAL9smLAnfPJCDUUG4ckX2iznj53V7VSMsYefzZieN93YxTNOcw@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/14e9b2a752efaa427ce1b400b9aaa5a636898a04

- Fix the overrun in hash index metapage for smaller block sizes.  The commit
  620b49a1 changed the value of HASH_MAX_BITMAPS with the intent to allow many
  non-unique values in hash indexes without worrying to reach the limit of the
  number of overflow pages.  At that time, this didn't occur to us that it can
  overrun the block for smaller block sizes.  Choose the value of
  HASH_MAX_BITMAPS based on BLCKSZ such that it gives the same answer as now for
  the cases where the overrun doesn't occur, and some other sufficiently-value
  for the cases where an overrun currently does occur.  This allows us not to
  change the behavior in any case that currently works, so there's really no
  reason for a HASH_VERSION bump.  Author: Dilip Kumar Reviewed-by: Amit Kapila
  Backpatch-through: 10 Discussion:
  https://postgr.es/m/CAA4eK1LtF4VmU4mx_+i72ff1MdNZ8XaJMGkt2HV8+uSWcn8t4A@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/ac27c74def5d8544530b13d5901308a342f072ac

Tom Lane pushed:

- Fully enforce uniqueness of constraint names.  It's been true for a long time
  that we expect names of table and domain constraints to be unique among the
  constraints of that table or domain.  However, the enforcement of that has
  been pretty haphazard, and it missed some corner cases such as creating a
  CHECK constraint and then an index constraint of the same name (as per recent
  report from André Hänsel).  Also, due to the lack of an actual unique index
  enforcing this, duplicates could be created through race conditions.
  Moreover, the code that searches pg_constraint has been quite inconsistent
  about how to handle duplicate names if one did occur: some places checked and
  threw errors if there was more than one match, while others just processed the
  first match they came to.  To fix, create a unique index on (conrelid,
  contypid, conname).  Since either conrelid or contypid is zero, this will
  separately enforce uniqueness of constraint names among constraints of any one
  table and any one domain.  (If we ever implement SQL assertions, and put them
  into this catalog, more thought might be needed.  But it'd be at least as
  reasonable to put them into a new catalog; having overloaded this one catalog
  with two kinds of constraints was a mistake already IMO.)  This index can
  replace the existing non-unique index on conrelid, though we need to keep the
  one on contypid for query performance reasons.  Having done that, we can
  simplify the logic in various places that either coped with duplicates or
  neglected to, as well as potentially improve lookup performance when searching
  for a constraint by name.  Also, as per our usual practice, install a
  preliminary check so that you get something more friendly than a unique-index
  violation report in the case complained of by André.  And teach
  ChooseIndexName to avoid choosing autogenerated names that would draw such a
  failure.  While it's not possible to make such a change in the back branches,
  it doesn't seem quite too late to put this into v11, so do so.  Discussion:
  https://postgr.es/m/0c1001d4428f$0942b430$1bc81c90$@webkr.de
  https://git.postgresql.org/pg/commitdiff/17b7c302b5fc92bd0241c452599019e18df074dc

- Clean up after TAP tests in oid2name and vacuumlo.  Oversights in commits
  1aaf532de and bfea331a5.  Unlike the case for traditional-style REGRESS tests,
  pgxs.mk doesn't have any builtin support for TAP tests, so it doesn't realize
  it should remove tmp_check/.  Maybe we should build some actual pgxs
  infrastructure for TAP tests ...  but for the moment, just remove explicitly.
  https://git.postgresql.org/pg/commitdiff/f30c6f523f9caa73c9ba6ebd82c8d29fe45866a3

- Make argument names of pg_get_object_address consistent, and fix docs.
  pg_get_object_address and pg_identify_object_as_address are supposed to be
  inverses, but they disagreed as to the names of the arguments representing the
  textual form of an object address.  Moreover, the documented argument names
  didn't agree with reality at all, either for these functions or
  pg_identify_object.  In HEAD and v11, I think we can get away with renaming
  the input arguments of pg_get_object_address to match the outputs of
  pg_identify_object_as_address.  In theory that might break queries using
  named-argument notation to call pg_get_object_address, but it seems really
  unlikely that anybody is doing that, or that they'd have much trouble
  adjusting if they were.  In older branches, we'll just live with the lack of
  consistency.  Aside from fixing the documentation of these functions to match
  reality, I couldn't resist the temptation to do some copy-editing.  Per
  complaint from Jean-Pierre Pelletier.  Back-patch to 9.5 where these functions
  were introduced.  (Before v11, this is a documentation change only.)
  Discussion:
  https://postgr.es/m/CANGqjDnWH8wsTY_GzDUxbt4i=y-85SJreZin4Hm8uOqv1vzRQA@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/ae5205c8a8eff6745fccd39b679ab9ee9c0d13c4

- Remove no-longer-used variable.  Oversight in 2fbdf1b38.  Per buildfarm.
  https://git.postgresql.org/pg/commitdiff/54b01b9293830d82d5b6c827771c683ff52ffb0b

- Make contrib/unaccent's unaccent() function work when not in search path.
  Since the fixes for CVE-2018-1058, we've advised people to schema-qualify
  function references in order to fix failures in code that executes under a
  minimal search_path setting.  However, that's insufficient to make the
  single-argument form of unaccent() work, because it looks up the "unaccent"
  text search dictionary using the search path.  The most expedient answer seems
  to be to remove the search_path dependency by making it look in the same
  schema that the unaccent() function itself is declared in.  This will
  definitely work for the normal usage of this function with the unaccent
  dictionary provided by the extension.  It's barely possible that there are
  people who were relying on the search-path-dependent behavior to select other
  dictionaries with the same name; but if there are any such people at all, they
  can still get that behavior by writing unaccent('unaccent', ...), or possibly
  unaccent('unaccent'::text::regdictionary, ...) if the lookup has to be
  postponed to runtime.  Per complaint from Gunnlaugur Thor Briem.  Back-patch
  to all supported branches.  Discussion:
  https://postgr.es/m/CAPs+M8LCex6d=DeneofdsoJVijaG59m9V0ggbb3pOH7hZO4+cQ@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/a5322ca10fa16bed01e3e3d6c49c0f49c68b5593

- Fix inconsistent argument naming.  Typo in commit 842cb9fa6.
  https://git.postgresql.org/pg/commitdiff/75f7855369ec56d4a8e7d6eae98aff1182b85cac

- Fix longstanding recursion hazard in sinval message processing.
  LockRelationOid and sibling routines supposed that, if our session already
  holds the lock they were asked to acquire, they could skip calling
  AcceptInvalidationMessages on the grounds that we must have already read any
  remote sinval messages issued against the relation being locked.  This is
  normally true, but there's a critical special case where it's not: processing
  inside AcceptInvalidationMessages might attempt to access system relations,
  resulting in a recursive call to acquire a relation lock.  Hence, if the outer
  call had acquired that same system catalog lock, we'd fall through, despite
  the possibility that there's an as-yet-unread sinval message for that system
  catalog.  This could, for example, result in failure to access a system
  catalog or index that had just been processed by VACUUM FULL.  This is the
  explanation for buildfarm failures we've been seeing intermittently for the
  past three months.  The bug is far older than that, but commits a54e1f158 et
  al added a new recursion case within AcceptInvalidationMessages that is
  apparently easier to hit than any previous case.  To fix this, we must not
  skip calling AcceptInvalidationMessages until we have *finished* a call to it
  since acquiring a relation lock, not merely acquired the lock.  (There's
  already adequate logic inside AcceptInvalidationMessages to deal with being
  called recursively.) Fortunately, we can implement that at trivial cost, by
  adding a flag to LOCALLOCK hashtable entries that tracks whether we know we
  have completed such a call.  There is an API hazard added by this patch for
  external callers of LockAcquire: if anything is testing for
  LOCKACQUIRE_ALREADY_HELD, it might be fooled by the new return code
  LOCKACQUIRE_ALREADY_CLEAR into thinking the lock wasn't already held.  This
  should be a fail-soft condition, though, unless something very bizarre is
  being done in response to the test.  Also, I added an additional output
  argument to LockAcquireExtended, assuming that that probably isn't called by
  any outside code given the very limited usefulness of its additional
  functionality.  Back-patch to all supported branches.  Discussion:
  https://postgr.es/m/12259.1532117714@sss.pgh.pa.us
  https://git.postgresql.org/pg/commitdiff/f868a8143a98c4172e3faaf415d9352179d5760b

- Limit depth of forced recursion for CLOBBER_CACHE_RECURSIVELY.  It's somewhat
  surprising that we got away with this before.  (Actually, since nobody tests
  this routinely AFAIK, it might've been broken for awhile.  But it's definitely
  broken in the wake of commit f868a8143.) It seems sufficient to limit the
  forced recursion to a small number of levels.  Back-patch to all supported
  branches, like the preceding patch.  Discussion:
  https://postgr.es/m/12259.1532117714@sss.pgh.pa.us
  https://git.postgresql.org/pg/commitdiff/f510412df3510e244fb3f9570ba5d2b4d27e773a

- Save/restore SPI's global variables in SPI_connect() and SPI_finish().  This
  patch removes two sources of interference between nominally independent
  functions when one SPI-using function calls another, perhaps without knowing
  that it does so.  Chapman Flack pointed out that xml.c's
  query_to_xml_internal() expects SPI_tuptable and SPI_processed to stay valid
  across datatype output function calls; but it's possible that such a call
  could involve re-entrant use of SPI.  It seems likely that there are similar
  hazards elsewhere, if not in the core code then in third-party SPI users.
  Previously SPI_finish() reset SPI's API globals to zeroes/nulls, which would
  typically make for a crash in such a situation.  Restoring them to the values
  they had at SPI_connect() seems like a considerably more useful behavior, and
  it still meets the design goal of not leaving any dangling pointers to tuple
  tables of the function being exited.  Also, cause SPI_connect() to reset these
  variables to zeroes/nulls after saving them.  This prevents interference in
  the opposite direction: it's possible that a SPI-using function that's only
  ever been tested standalone contains assumptions that these variables start
  out as zeroes.  That was the case as long as you were the outermost SPI user,
  but not so much for an inner user.  Now it's consistent.  Report and fix
  suggestion by Chapman Flack, actual patch by me.  Back-patch to all supported
  branches.  Discussion:
  https://postgr.es/m/9fa25bef-2e4f-1c32-22a4-3ad0723c4a17@anastigmatix.net
  https://git.postgresql.org/pg/commitdiff/361844fe561f6898d90a10382705ad968929a4b2

- Minor cleanup/future-proofing for pg_saslprep().  Ensure that pg_saslprep()
  initializes its output argument to NULL in all failure paths, and then remove
  the redundant initialization that some (not all) of its callers did.  This
  does not fix any live bug, but it reduces the odds of future bugs of omission.
  Also add a comment about why the existing failure-path coding is adequate.
  Back-patch so as to keep the function's API consistent across branches, again
  to forestall future bug introduction.  Patch by me, reviewed by Michael
  Paquier Discussion: https://postgr.es/m/16558.1536407783@sss.pgh.pa.us
  https://git.postgresql.org/pg/commitdiff/f47f3148011f1cb5dc34396382fc2f434844d247

- Install a check for mis-linking of src/port and src/common functions.  On
  ELF-based platforms (and maybe others?) it's possible for a shared library,
  when dynamically loaded into the backend, to call the backend versions of
  src/port and src/common functions rather than the frontend versions that are
  actually linked into the shlib.  This is definitely not what we want, because
  the frontend versions often behave slightly differently.  Up to now it's been
  "slight" enough that nobody noticed; but with the addition of SCRAM support
  functions in src/common, we're observing crashes due to the difference between
  palloc and malloc memory allocation rules, as reported in bug #15367 from
  Jeremy Evans.  The purpose of this patch is to create a direct test for this
  type of mis-linking, so that we know whether any given platform requires extra
  measures to prevent using the wrong functions.  If the test fails, it will
  lead to connection failures in the contrib/postgres_fdw regression test.  At
  the moment, *BSD platforms using ELF format are known to have the problem and
  can be expected to fail; but we need to know whether anything else does, and
  we need a reliable ongoing check for future platforms.  Actually fixing the
  problem will be the subject of later commit(s).  Discussion:
  https://postgr.es/m/153626613985.23143.4743626885618266803@wrigleys.postgresql.org
  https://git.postgresql.org/pg/commitdiff/ed0cdf0e05134d1084b01bf8a77e9e1dc5081f91

- Work around stdbool problem in dfmgr.c.  Commit 842cb9fa6 refactored things so
  that dfmgr.c includes <dlfcn.h>, which before that had only been directly
  included in platform-specific stub files.  It turns out that on macOS,
  <dlfcn.h> includes <stdbool.h>, and that causes problems on platforms where
  _Bool is not char-sized ...  which happens to include the PPC versions of
  macOS.  Work around it much as we have in plperl.h, by #undef'ing bool after
  including the problematic file, but only if we're not using stdbool-style
  booleans.  Discussion:
  https://postgr.es/m/E1fxqjl-0003YS-NS@gemulon.postgresql.org
  https://git.postgresql.org/pg/commitdiff/ff47d4bf1f208227a2e087ef7269e88285fa257e

- Prevent mis-linking of src/port and src/common functions on *BSD.  On
  ELF-based platforms (and maybe others?) it's possible for a shared library,
  when dynamically loaded into the backend, to call the backend versions of
  src/port and src/common functions rather than the frontend versions that are
  actually linked into the shlib.  This is the cause of bug #15367 from Jeremy
  Evans, and is likely to lead to more problems in future; it's accidental that
  we've failed to notice any bad effects up to now.  The recommended way to fix
  this on ELF-based platforms is to use a linker "version script" that makes the
  shlib's versions of the functions local.  (Apparently, -Bsymbolic would fix it
  as well, but with other side effects that we don't want.)  Doing so has the
  additional benefit that we can make sure the shlib only exposes the symbols
  that are meant to be part of its API, and not ones that are just for
  cross-file references within the shlib.  So we'd already been using a version
  script for libpq on popular platforms, but it's now apparent that it's
  necessary for correctness on every ELF-based platform.  Hence, add appropriate
  logic to the openbsd, freebsd, and netbsd stanzas of Makefile.shlib; this is
  just a copy-and-paste from the linux stanza.  There may be additional work to
  do if commit ed0cdf0e0 reveals that the problem exists elsewhere, but this is
  all that is known to be needed right now.  Back-patch to v10 where SCRAM
  support came in.  The problem is ancient, but analysis suggests that there
  were no really severe consequences in older branches.  Hence, I won't take the
  risk of such a large change in the build process for older branches.  In
  passing, remove a rather opaque comment about -Bsymbolic; I don't think it's
  very on-point about why we don't use that, if indeed that's what it's talking
  about at all.  Patch by me; thanks to Andrew Gierth for helping to diagnose
  the problem, and for additional testing.  Discussion:
  https://postgr.es/m/153626613985.23143.4743626885618266803@wrigleys.postgresql.org
  https://git.postgresql.org/pg/commitdiff/e3d77ea6b4e425093db23be492f236896dd7b501

Michaël Paquier pushed:

- Improve some error message strings and errcodes.  This makes a bit less work
  for translators, by unifying error strings a bit more with what the rest of
  the code does, this time for three error strings in autoprewarm and one in
  base backup code.  After some code review of slot.c, some file-access errcodes
  are reported but lead to an incorrect internal error, while corrupted data
  makes the most sense, similarly to the previous work done in e41d0a1.  Also,
  after calling rmtree(), a WARNING gets reported, which is a duplicate of what
  the internal call report, so make the code more consistent with all other code
  paths calling this function.  Author: Michael Paquier Discussion:
  https://postgr.es/m/20180902200747.GC1343@paquier.xyz
  https://git.postgresql.org/pg/commitdiff/d6e98ebe375e115c29028f9bd090f0f7e07e2527

- Improve handling of corrupted two-phase state files at recovery.  When a
  corrupted two-phase state file is found by WAL replay, be it for crash
  recovery or archive recovery, then the file is simply skipped and a WARNING is
  logged to the user, causing the transaction to be silently lost.  Facing an
  on-disk WAL file which is corrupted is as likely to happen as what is stored
  in WAL records, but WAL records are already able to fail hard if there is a
  CRC mismatch.  On-disk two-phase state files, on the contrary, are simply
  ignored if corrupted.  Note that when restoring the initial two-phase data
  state at recovery, files newer than the horizon XID are discarded hence no
  files present in pg_twophase/ should be torned and have been made durable by a
  previous checkpoint, so recovery should never see any corrupted two-phase
  state file by design.  The situation got better since 978b2f6 which has added
  two-phase state information directly in WAL instead of using on-disk files, so
  the risk is limited to two-phase transactions which live across at least one
  checkpoint for long periods.  Backups having legit two-phase state files
  on-disk could also lose silently transactions when restored if things get
  corrupted.  This behavior exists since two-phase commit has been introduced,
  no back-patch is done for now per the lack of complaints about this problem.
  Author: Michael Paquier Discussion:
  https://postgr.es/m/20180709050309.GM1467@paquier.xyz
  https://git.postgresql.org/pg/commitdiff/8582b4d044b05d3fe4bcdf6e039fde8e753934ae

- Remove duplicated words split across lines in comments.  This has been
  detected using some interesting tricks with sed, and the method used is
  mentioned in details in the discussion below.  Author: Justin Pryzby
  Discussion: https://postgr.es/m/20180908013109.GB15350@telsasoft.com
  https://git.postgresql.org/pg/commitdiff/9226a3b89b004b3472d963442856206f0c249a53

Bruce Momjian pushed:

- docs:  improve AT TIME ZONE description.  The previous description was
  unclear.  Also add a third example, change use of time zone acronyms to more
  verbose descriptions, and add a mention that using 'time' with AT TIME ZONE
  uses the current time zone rules.  Backpatch-through: 9.3
  https://git.postgresql.org/pg/commitdiff/dd6073f22a6b5dd6181d8324465dd3c0bf1851e8

Peter Eisentraut pushed:

- PL/Python: Remove use of simple slicing API.  The simple slicing API
  (sq_slice, sq_ass_slice) has been deprecated since Python 2.0 and has been
  removed altogether in Python 3, so remove those functions from the PLyResult
  class.  Instead, the non-slice mapping functions mp_subscript and
  mp_ass_subscript can take slice objects as an index.  Since we just pass the
  index through to the underlying list object, we already support that.  Test
  coverage was already in place.
  https://git.postgresql.org/pg/commitdiff/f5a6509bb1ec5222a707205941a40f280f3e6e15

- Refactor dlopen() support.  Nowadays, all platforms except Windows and older
  HP-UX have standard dlopen() support.  So having a separate implementation per
  platform under src/backend/port/dynloader/ is a bit excessive.  Instead, treat
  dlopen() like other library functions that happen to be missing sometimes and
  put a replacement implementation under src/port/.  Discussion:

https://www.postgresql.org/message-id/flat/e11a49cb-570a-60b7-707d-7084c8de0e61%402ndquadrant.com#54e735ae37476a121abb4e33c2549b03
  https://git.postgresql.org/pg/commitdiff/842cb9fa62fc99598086166bdeec9d6ae6e3c50f

- Use C99 designated initializers for some structs.  These are just a few
  particularly egregious cases that were hard to read and write, and error prone
  because of many similar adjacent types.  Discussion:
  https://www.postgresql.org/message-id/flat/4c9f01be-9245-2148-b569-61a8562ef190%402ndquadrant.com
  https://git.postgresql.org/pg/commitdiff/98afa68d935215e8ab2c7de7fb45972a03e3da26

- libpq: Change "options" dispchar to normal.  libpq connection options as
  returned by PQconndefaults() have a "dispchar" field that determines (among
  other things) whether an option is a "debug" option, which shouldn't be shown
  by default to clients.  postgres_fdw makes use of that to control which
  connection options to accept from a foreign server configuration.  Curiously,
  the "options" option, which allows passing configuration settings to the
  backend server, was listed as a debug option, which prevented it from being
  used by postgres_fdw.  Maybe it was once meant for debugging, but it's clearly
  in general use nowadays.  So change the dispchar for it to be the normal
  non-debug case.  Also remove the "debug" reference from its label field.
  Reported-by: Shinoda, Noriyoshi <noriyoshi.shinoda@hpe.com>
  https://git.postgresql.org/pg/commitdiff/1fea1e325492b10f645809204631426bb6abbe6e

Andrew Gierth pushed:

- Refactor installation of extension headers.  Commit be54b3777 failed on gmake
  3.80 due to a chained conditional, which on closer examination could be
  removed entirely with some refactoring elsewhere for a net simplification and
  more robustness against empty expansions. Along the way, add some more
  comments.  Also make explicit in the documentation and comments that built
  headers are not removed by 'make clean', since we don't typically want that
  for headers generated by a separate ./configure step, and it's much easier to
  add your own 'distclean' rule or use EXTRA_CLEAN than to try and override a
  deletion rule in pgxs.mk.  Per buildfarm member prariedog and comments by
  Michael Paquier, though all the actual changes are my fault.
  https://git.postgresql.org/pg/commitdiff/7b6b167fa3bd2f968ad885ca7b024be4122a85f1

- Allow extensions to install built as well as unbuilt headers.  Commit
  df163230b overlooked the case that an out-of-tree extension might need to
  build its header files (e.g. via ./configure). If it is also doing a VPATH
  build, the HEADERS_* rules in the original commit would then fail to find the
  files, since they would be looking only under $(srcdir) and not in the build
  directory.  Fix by adding HEADERS_built and HEADERS_built_$(MODULE) which
  behave like DATA_built in that they look in the build dir rather than the
  source dir (and also make the files dependencies of the "all" target).  No
  Windows support appears to be needed for this, since it is only relevant to
  out-of-tree builds (no support exists in Mkvcbuild.pm to build extension
  header files in any case).
  https://git.postgresql.org/pg/commitdiff/be54b3777ff189e79661d8746d3f25b0564393d2

Noah Misch pushed:

- Fix logical subscriber wait in test.  Buildfarm members sungazer and tern
  revealed this deficit.  Back-patch to v10, like commit
  4f10e7ea7b2231f453bb18b6e710ac333eaf121b, which introduced the test.
  https://git.postgresql.org/pg/commitdiff/076a3c2112b127b3b36346dbc64659f9a165f60f

- Allow ENOENT in check_mode_recursive().  Buildfarm member tern failed
  src/bin/pg_ctl/t/001_start_stop.pl when a check_mode_recursive() call
  overlapped a server's startup-time deletion of pg_stat/global.stat.  Just
  warn.  Also, include errno in the message.  Back-patch to v11, where
  check_mode_recursive() first appeared.
  https://git.postgresql.org/pg/commitdiff/c85ad9cc63e1487758f3969e20826cac0e944a27

Alexander Korotkov pushed:

- Improve behavior of to_timestamp()/to_date() functions.
  to_timestamp()/to_date() functions were introduced mainly for Oracle
  compatibility, and became very popular among PostgreSQL users.  However, some
  behavior of to_timestamp()/to_date() functions are both incompatible with
  Oracle and confusing for our users.  This behavior is related to handling of
  spaces and separators in non FX (fixed format) mode.  This commit reworks this
  behavior making less confusing, better documented and more compatible with
  Oracle.  Nevertheless, there are still following incompatibilities with
  Oracle.  1) We don't insist that there are no format string patterns unmatched
  to input string.  2) In FX mode we don't insist space and separators in format
  string to exactly match input string.  3) When format string patterns are
  divided by mix of spaces and separators, we don't distinguish them, while
  Oracle takes into account only last group of spaces/separators.  Discussion:
  https://postgr.es/m/1873520224.1784572.1465833145330.JavaMail.yahoo%40mail.yahoo.com
  Author: Artur Zakirov, Alexander Korotkov, Liudmila Mantrova Review: Amul Sul,
  Robert Haas, Tom Lane, Dmitry Dolgov, David G. Johnston
  https://git.postgresql.org/pg/commitdiff/cf984672427ebc4446213fe8f71d8899452802b6

- Fix past pd_upper write in ginRedoRecompress().  ginRedoRecompress() replays
  actions over compressed segments of posting list in-place.  However, it might
  lead to write past pg_upper, because intermediate state during playing the
  changes can take more space than both original state and final state.  This
  commit fixes that by refuse from in-place modification.  Instead page tail is
  copied once modification is started, and then it's used as the source of
  original segments.  Backpatch to 9.4 where posting list compression was
  introduced.  Reported-by: Sivasubramanian Ramasubramanian Discussion:
  https://postgr.es/m/1536091151804.6588%40amazon.com Author: Alexander Korotkov
  based on patch from and ideas by Sivasubramanian Ramasubramanian Review:
  Sivasubramanian Ramasubramanian Backpatch-through: 9.4
  https://git.postgresql.org/pg/commitdiff/5f08accdad2b03e0107bdc73d48783a01fe51c8c

== Pending Patches ==

Dilip Kumar sent in another revision of a patch to implement UNDO logs.

Yugo Nagata sent in another revision of a patch to enable pg_verify_checksums to
specify a database to scan.

Tomáš Vondra sent in another revision of a patch to enable multivariate
histograms and MCV lists.

Haribabu Kommi sent in a patch to limit the memory used by COPY FROM because of
slotification and teach the make the FDW RefetchForeignRow API use
TupleTableSlot.

Álvaro Herrera sent in two revisions of a patch to remove a pointless check in
RelationBuildPartitionDesc.

Dilip Kumar sent in two revisions of a patch to fix a pg_verify_checksums
failure with hash indexes.

Masahiko Sawada sent in another revision of a patch to implement CREATE ROUTINE
MAPPING.

Amit Langote sent in another revision of a patch to stop locking range table
relations in the executor, remove some fields from the planner nodes that are no
longer needed as a consequence of that, prune the PlanRowMark of relations that
are pruned from a plan, and revise the executor range table relation
opening/closing.

Amit Khandekar sent in another revision of a patch to implement the
TableTupleSlot abstraction.

Pavan Deolasee sent in two more revisions of a patch to implement MERGE.

Chi Gao and Alexander Korotkov traded patches to to make it possible to get hash
and merge joins for IS NOT DISTINCT FROM conditions in a JOIN.

Michaël Paquier sent in two revisions of a patch to fix an issue where
test_pg_dump was not cleaning up after itself.

Kyotaro HORIGUCHI sent in another revision of a patch to add a WAL relief vent
for replication slots, columns "status" and "remain" in pg_replication_slot as a
monitoring aid for max_slot_wal_keep_size, and TAP tests and documentation for
same.

Thomas Munro sent in three revisions of a patch to add a
libc_collation_version_command GUC and autocompletion for ALTER COLLATION ...
REFRESH VERSION in psql.

Stas Kelvich and Nikita Glukhov traded patches to implement JSONPATH.

Nathan Bossart sent in another revision of a patch to add SKIP LOCKED to VACUUM
and ANALYZE.

Álvaro Herrera sent in a patch to fix a discrepancy between
pg_identify_object_as_address()'s documented arguments and its actual ones.

Victor Spirin sent in a patch to fix an issue where PostgreSQL does not start
when max_files_per_process is greater than 1200 on Windows 7.

Richard Guo sent in a patch to implement predicate propagation for
non-equivalence clauses.

Andrey V. Lepikhov sent in two more revisions of a patch to implement a heap-
and index-cleaner at a retail level.

Kyotaro HORIGUCHI sent in a patch to ignore fillfactor in GiST indexes.

Marina Polyakova sent in another revision of a patch to handle and retry
transactions with serialization/deadlock failures in pgbench.

Jimmy Yih and Michaël Paquier traded patches to fix some locking issues around
DROP SCHEMA.

Naoki Yotsunaga sent in another revision of a patch to add a log_recovery_points
GUC.

Michaël Paquier sent in a patch to add extension options to control TAP and
isolation tests.

Aleksandr Parfenov sent in another revision of a patch to speed up queries which
contain immutable functions used as relations.

Chris Travers sent in four more revisions of a patch to fix a race condition
between the startup process and parallel workers.

Ildus Kurbangaliev sent in another revision of a patch to add custom compression
methods.

Pavel Stěhule sent in another revision of a patch to implement schema variables.

Tom Lane sent in another revision of a patch to avoid depending on search path
in unaccent.

David Rowley sent in a patch to improve the performance of run-time partition
pruning.

Yugo Nagata sent in a patch to remove an unused argument from
execute_sql_string().

Peter Moser sent in another revision of a patch to add NORMALIZE, a part of
doing temporal queries.

Maksim Milyutin sent in a patch to add a hint to set the owner for a tablespace
directory when setting permissions on same fails during creation.

Thomas Munro sent in another revision of a patch to make libpq check integers
more strictly. Previously, it had permitted trailing garbage and overflows.

Thomas Munro sent in a patch to serialize the enum blacklist state.

Justin Pryzby sent in a patch to remove duplicated words in comments across
lines.