Skip site navigation (1) Skip section navigation (2)

== PostgreSQL Weekly News - January 14 2018 ==

From: David Fetter <david(at)fetter(dot)org>
To: PostgreSQL Announce <pgsql-announce(at)postgresql(dot)org>
Subject: == PostgreSQL Weekly News - January 14 2018 ==
Date: 2018-01-14 20:09:09
Message-ID: 20180114200909.GA11243@fetter.org (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-announcepgsql-www
== PostgreSQL Weekly News - January 14 2018 ==

== PostgreSQL Product News ==

Pgpool-II 3.7.1, 3.6.8, 3.5.12, 3.4.15 and 3.3.19 released.
http://www.pgpool.net/docs/latest/en/html/release.html

pglogical 2.1.1, a logical-WAL-based replication system for PostgreSQL, released.
https://www.2ndquadrant.com/en/resources/pglogical/

== PostgreSQL Jobs for January ==

http://archives.postgresql.org/pgsql-jobs/2018-01/

== PostgreSQL Local ==

FOSDEM PGDay 2018, a one day conference held before the main FOSDEM event will
be held in Brussels, Belgium, on Feb 2nd, 2018.
https://2018.fosdempgday.org/

Prague PostgreSQL Developer Day 2018 (P2D2 2018) is a two-day
conference that will be held on February 14-15 2018 in Prague, Czech Republic.
http://www.p2d2.cz/

PGConf India 2018 will be on February 22-23, 2018 in Bengaluru, Karnataka.
http://pgconf.in/

PostgreSQL(at)SCaLE is a two day, two track event which takes place on
March 8-9, 2018, at Pasadena Convention Center, as part of SCaLE 16X.
http://www.socallinuxexpo.org/scale/16x/cfp

Nordic PGDay 2018 will be held in Oslo, Norway, at the Radisson Blu Hotel
Nydalen, on March 13, 2018.  The CfP is open through December 31, 2017 at
https://2018.nordicpgday.org/cfp/

pgDay Paris 2018 will be held in Paris, France at the Espace Saint-Martin, on
March 15 2018.  The CfP is open until December 31, 2017.
http://2018.pgday.paris/callforpapers/

PGConf APAC 2018 will be held in Singapore March 22-23, 2018.
http://2018.pgconfapac.org/

The German-speaking PostgreSQL Conference 2018 will take place on April 13th,
2018 in Berlin.
http://2018.pgconf.de/

PGConfNepal 2018 will be held May 4-5, 2018 at Kathmandu University, Dhulikhel,
Nepal.  The CfP is open until 2018-02-01 at
https://postgresconf.org/conferences/Nepal2018/program/proposals
https://postgresconf.org/conferences/Nepal2018

PGCon 2018 will take place in Ottawa on May 29 - June 1, 2018.  The CFP is open
until January 19, 2018 at https://www.pgcon.org/2018/papers.php
https://www.pgcon.org/2018/

PGConf.Brazil 2018 will take place in São Paulo, Brazil on August 3-4 2018. The
CfP will open soon.
http://pgconf.com.br

== 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 EST5EDT.  Please send English
language ones to david(at)fetter(dot)org, German language to pwn(at)pgug(dot)de, Italian
language to pwn(at)itpug(dot)org(dot)

== Applied Patches ==

Tom Lane pushed:

- Back off chattiness in RemovePgTempFiles().  In commit 561885db0, as part of
  normalizing RemovePgTempFiles's error handling, I removed its behavior of
  silently ignoring ENOENT failures during directory opens.  Thomas Munro points
  out that this is a bad idea at the top level, because we don't create
  pgsql_tmp directories until needed.  Thus this coding could produce LOG
  messages in perfectly normal situations, which isn't what I intended.  Restore
  the suppression of ENOENT logging, but only at top level --- it would still be
  unexpected for a nested temp directory to disappear between seeing it in the
  parent directory and opening it.  Discussion:
  https://postgr.es/m/CAEepm=2y06SehAkTnd5sU_eVqdv5P-=Srt1y5vYNQk6yVDVaPw@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/eeb3c2df429c943b2f8d028d110b55ac0a53dc75

- Cosmetic improvements in condition_variable.[hc].  Clarify a bunch of
  comments.  Discussion:
  https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/e35dba475a440f73dccf9ed1fd61e3abc6ee61db

- Improve error detection capability in proclists.  Previously, although the
  initial state of a proclist_node is expected to be next == prev == 0,
  proclist_delete_offset would reset nodes to next == prev == INVALID_PGPROCNO
  when removing them from a list.  This is the same state that a node in a
  singleton list has, so that it's impossible to distinguish not-in-a-list from
  in-a-list.  Change proclist_delete_offset to reset removed nodes to next ==
  prev == 0, making it possible to distinguish those cases, and then add Asserts
  to the list add and delete functions that the supplied node isn't or is in a
  list at entry.  Also tighten assertions about the node being in the particular
  list (not some other one) where it is possible to check that in O(1) time.  In
  ConditionVariablePrepareToSleep, since we don't expect the process's
  cvWaitLink to already be in a list, remove the more-or-less-useless
  proclist_contains check; we'd rather have proclist_push_tail's new assertion
  fire if that happens.  Improve various comments related to proclists, too.
  Patch by me, reviewed by Thomas Munro.  This isn't back-patchable, since there
  could theoretically be inlined copies of proclist_delete_offset in third-party
  modules.  But it's only improving debuggability anyway.  Discussion:
  https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/ea8e1bbc538444d373cf712a0f5188c906b71a9d

- Allow ConditionVariable[PrepareTo]Sleep to auto-switch between CVs.  The
  original coding here insisted that callers manually cancel any prepared sleep
  for one condition variable before starting a sleep on another one.  While
  that's not a huge burden today, it seems like a gotcha that will bite us in
  future if the use of condition variables increases; anything we can do to make
  the use of this API simpler and more robust is attractive.  Hence, allow these
  functions to automatically switch their attention to a different CV when
  required.  This is safe for the same reason it was OK for commit aced5a92b to
  let a broadcast operation cancel any prepared CV sleep: whenever we return to
  the other test-and-sleep loop, we will automatically re-prepare that CV,
  paying at most an extra test of that loop's exit condition.  Back-patch to v10
  where condition variables were introduced.  Ordinarily we would probably not
  back-patch a change like this, but since it does not invalidate any coding
  pattern that was legal before, it seems safe enough.  Furthermore, there's an
  open bug in replorigin_drop() for which the simplest fix requires this.  Even
  if we chose to fix that in some more complicated way, the hazard would remain
  that we might back-patch some other bug fix that requires this behavior.
  Patch by me, reviewed by Thomas Munro.  Discussion:
  https://postgr.es/m/2437.1515368316@sss.pgh.pa.us
  https://git.postgresql.org/pg/commitdiff/13db3b936359eebf02a768db3a1959af880b6cc6

- Fix race condition during replication origin drop.  replorigin_drop()
  misunderstood the API for condition variables: it had
  ConditionVariablePrepareToSleep and ConditionVariableCancelSleep inside its
  test-and-sleep loop, rather than outside the loop as intended.  The net effect
  is a narrow race-condition window wherein, if the process using a replication
  slot releases it immediately after replorigin_drop() releases the
  ReplicationOriginLock, replorigin_drop() would get into the condition
  variable's wait list too late and then wait indefinitely for a signal that
  won't come.  Because there's a different CV for each replication slot, we
  can't just move the ConditionVariablePrepareToSleep call to above the
  test-and-sleep loop.  What we can do, in the wake of commit 13db3b936, is drop
  the ConditionVariablePrepareToSleep call entirely.  This fix depends on that
  commit because (at least in principle) the slot matching the target
  replication origin might move around, so that once in a blue moon successive
  loop iterations might involve different CVs.  We can now cope with such a
  scenario, at the cost of an extra trip through the retry loop.  (There are
  ways we could fix this bug without depending on that commit, but they're all a
  lot more complicated than this way.) While at it, upgrade the rather skimpy
  comments in this function.  Back-patch to v10 where this code came in.
  Discussion: https://postgr.es/m/19947.1515455433@sss.pgh.pa.us
  https://git.postgresql.org/pg/commitdiff/8a906204aec44de6d8a1514082870f25085d9431

- While waiting for a condition variable, detect postmaster death.  The general
  assumption for postmaster child processes is that they should just exit(1),
  reasonably promptly, if the postmaster disappears.  condition_variable.c
  neglected this consideration and could be left waiting forever, if the
  counterpart process it is waiting for has done the right thing and exited.  We
  had some discussion of adjusting the WaitEventSet API to make it harder to
  make this type of mistake in future; but for the moment, and for v10, let's
  make this narrow fix.  Discussion:
  https://postgr.es/m/20412.1515456143@sss.pgh.pa.us
  https://git.postgresql.org/pg/commitdiff/80259d4dbf47d13ef4c105e06c4ea084639d9466

- Rewrite list_qsort() to avoid trashing its input list.  The initial
  implementation of list_qsort(), from commit ab7271677, re-used the ListCells
  of the input list while not touching the List header.  This meant that anybody
  who still had a pointer to the original header would now be in possession of a
  corrupted list, a problem that seems sure to bite us eventually.  One possible
  solution is to re-use the original List header as well, giving the function
  the semantics of update-in-place.  However, that doesn't seem like a very good
  idea either given the way that the function is used in the planner:
  create_path functions aren't normally supposed to modify their input lists.
  It doesn't look like there would be a problem today, but it's not hard to
  foresee a time when modifying a list of Paths in-place could have side-effects
  on some other append path.  On the whole, and in view of the likelihood that
  this function might be used in other contexts in the future, it seems best to
  get rid of the micro-optimization of re-using the input list cells.  Just
  build a new list.  Discussion:
  https://postgr.es/m/16912.1515449066@sss.pgh.pa.us
  https://git.postgresql.org/pg/commitdiff/3cb1b2a8804da8365fe17f687d96b720df4a583d

- Improve the heuristic for ordering child paths of a parallel append.  Commit
  ab7271677 introduced code that attempts to order the child scans of a Parallel
  Append node in a way that will minimize execution time, based on total cost
  and startup cost.  However, it failed to think hard about what to do when
  estimated costs are exactly equal; a case that's particularly likely to occur
  when comparing on startup cost.  In such a case the ordering of the child
  paths would be left to the whims of qsort, an algorithm that isn't even
  stable.  We can improve matters by applying the rule used elsewhere in the
  planner: if total costs are equal, sort on startup cost, and vice versa.  When
  both cost estimates are exactly equal, rather than letting qsort do something
  unpredictable, sort based on the child paths' relids, which should typically
  result in sorting in inheritance order.  (The latter provision requires
  inventing a qsort-style comparator for bitmapsets, but maybe we'll have use
  for that for other reasons in future.) This results in a few plan changes in
  the select_parallel test, but those all look more reasonable than before, when
  the actual underlying cost numbers are taken into account.  Discussion:
  https://postgr.es/m/4944.1515446989@sss.pgh.pa.us
  https://git.postgresql.org/pg/commitdiff/624e440a474420fa0d6cf26c19bfb256547ab71d

- Remove dubious micro-optimization in ckpt_buforder_comparator().  It seems
  incorrect to assume that the list of CkptSortItems can never contain duplicate
  page numbers: concurrent activity could result in some page getting dropped
  from a low-numbered buffer and later loaded into a high-numbered buffer while
  BufferSync is scanning the buffer pool.  If that happened, the comparator
  would give self-inconsistent results, potentially confusing qsort().  Saving
  one comparison step is not worth possibly getting the sort wrong.  So far as I
  can tell, nothing would actually go wrong given our current implementation of
  qsort().  It might get a bit slower than expected if there were a large number
  of duplicates of one value, but that's surely a probability-epsilon case.
  Still, the comment is wrong, and if we ever switched to another sort
  implementation it might be less forgiving.  In passing, avoid casting away
  const-ness of the argument pointers; I've not seen any compiler complaints
  from that, but it seems likely that some compilers would not like it.
  Back-patch to 9.6 where this code came in, just in case I've underestimated
  the possible consequences.  Discussion:
  https://postgr.es/m/18437.1515607610@sss.pgh.pa.us
  https://git.postgresql.org/pg/commitdiff/3afd75eaac8aaccf5aeebc52548c396b84d85516

- Fix sample INSTR() functions in the plpgsql documentation.  These functions
  are stated to be Oracle-compatible, but they weren't.  Yugo Nagata noticed
  that while our code returns zero for a zero or negative fourth parameter
  (occur_index), Oracle throws an error.  Further testing by me showed that
  there was also a discrepancy in the interpretation of a negative third
  parameter (beg_index): Oracle thinks that a negative beg_index indicates the
  last place where the target substring can *begin*, whereas our code thinks it
  is the last place where the target can *end*.  Adjust the sample code to
  behave like Oracle in both these respects.  Also change it to be a CDATA[]
  section, simplifying copying-and-pasting out of the documentation source file.
  And fix minor problems in the introductory comment, which wasn't very complete
  or accurate.  Back-patch to all supported branches.  Although this patch only
  touches documentation, we should probably call it out as a bug fix in the next
  minor release notes, since users who have adopted the functions will likely
  want to update their versions.  Yugo Nagata and Tom Lane Discussion:
  https://postgr.es/m/20171229191705.c0b43a8c.nagata@sraoss.co.jp
  https://git.postgresql.org/pg/commitdiff/3c1e9fd23269849e32c73683a8457fb3095309e3

- Cosmetic fix in postgres_fdw.c.  Make the forward declaration of
  estimate_path_cost_size match its actual definition.  Tatsuro Yamada
  Discussion:
  https://postgr.es/m/96f2f554-1eeb-fe6f-e0db-650771886781@lab.ntt.co.jp
  https://git.postgresql.org/pg/commitdiff/9ff4f758ee430dbce0be13ab5da315be52cb6f55

- Add QueryEnvironment to ExplainOneQuery_hook's parameter list.  This should
  have been done in commit 18ce3a4ab, which added that parameter to
  ExplainOneQuery, but it was overlooked.  This makes it impossible for a user
  of the hook to pass the queryEnv down to ExplainOnePlan.  It's too late to
  change this API in v10, I suppose, but fortunately passing NULL to
  ExplainOnePlan will work in nearly all interesting cases in v10.  That might
  not be true forever, so we'd better fix it.  Tatsuro Yamada, reviewed by
  Thomas Munro Discussion:
  https://postgr.es/m/890e8dd9-c1c7-a422-6892-874f5eaee048@lab.ntt.co.jp
  https://git.postgresql.org/pg/commitdiff/4d41b2e0926548e338d20875729a55d41289f867

- Fix incorrect handling of subquery pullup in the presence of grouping sets.
  If we flatten a subquery whose target list contains constants or expressions,
  when those output columns are used in GROUPING SET columns, the planner was
  capable of doing the wrong thing by merging a pulled-up expression into the
  surrounding expression during const-simplification.  Then the late processing
  that attempts to match subexpressions to grouping sets would fail to match
  those subexpressions to grouping sets, with the effect that they'd not go to
  null when expected.  To fix, wrap such subquery outputs in PlaceHolderVars,
  ensuring that they preserve their separate identity throughout the planner's
  expression processing.  This is a bit of a band-aid, because the wrapper
  defeats const-simplification even in places where it would be safe to allow.
  But a nicer fix would likely be too invasive to back-patch, and the
  consequences of the missed optimizations probably aren't large in most cases.
  Back-patch to 9.5 where grouping sets were introduced.  Heikki Linnakangas,
  with small mods and better test cases by me; additional review by Andrew
  Gierth Discussion:
  https://postgr.es/m/7dbdcf5c-b5a6-ef89-4958-da212fe10176@iki.fi
  https://git.postgresql.org/pg/commitdiff/90947674fc984f5639e3b1bf013435a023aa713b

- Avoid unnecessary failure in SELECT concurrent with ALTER NO INHERIT.  If a
  query against an inheritance tree runs concurrently with an ALTER TABLE that's
  disinheriting one of the tree members, it's possible to get a "could not find
  inherited attribute" error because after obtaining lock on the removed member,
  make_inh_translation_list sees that its columns have attinhcount=0 and decides
  they aren't the columns it's looking for.  An ideal fix, perhaps, would avoid
  including such a just-removed member table in the query at all; but there
  seems no way to accomplish that without adding expensive catalog rechecks or
  creating a likelihood of deadlocks.  Instead, let's just drop the check on
  attinhcount.  In this way, a query that's included a just-disinherited child
  will still succeed, which is not a completely unreasonable behavior.  This
  problem has existed for a long time, so back-patch to all supported branches.
  Also add an isolation test verifying related behaviors.  Patch by me; the new
  isolation test is based on Kyotaro Horiguchi's work.  Discussion:
  https://postgr.es/m/20170626.174612.23936762.horiguchi.kyotaro@lab.ntt.co.jp
  https://git.postgresql.org/pg/commitdiff/680d540502609b422d378a1b8e0c10cac3c60084

- Fix postgres_fdw to cope with duplicate GROUP BY entries.  Commit 7012b132d,
  which added the ability to push down aggregates and grouping to the remote
  server, wasn't careful to ensure that the remote server would have the same
  idea we do about which columns are the grouping columns, in cases where there
  are textually identical GROUP BY expressions.  Such cases typically led to
  "targetlist item has multiple sortgroupref labels" errors.  To fix this
  reliably, switch over to using "GROUP BY column-number" syntax rather than
  "GROUP BY expression" in transmitted queries, and adjust foreign_grouping_ok()
  to be more careful about duplicating the sortgroupref labeling of the local
  pathtarget.  Per bug #14890 from Sean Johnston.  Back-patch to v10 where the
  buggy code was introduced.  Jeevan Chalke, reviewed by Ashutosh Bapat
  Discussion:
  https://postgr.es/m/20171107134948.1508.94783@wrigleys.postgresql.org
  https://git.postgresql.org/pg/commitdiff/e9f2703ab7b29f7e9100807cfbd19ddebbaa0b12

Bruce Momjian pushed:

- pg_upgrade:  prevent check on live cluster from generating error.  Previously
  an inaccurate but harmless error was generated when running --check on a live
  server before reporting the servers as compatible.  The fix is to split error
  reporting and exit control in the exec_prog() API.  Reported-by: Daniel
  Westermann Backpatch-through: 10
  https://git.postgresql.org/pg/commitdiff/d25ee30031b08ad1348a090914c2af6bc640a832

- Remove outdated/removed Win32 URLs in C comments.  Reported-by: Ashutosh
  Sharma
  https://git.postgresql.org/pg/commitdiff/fccaea45496d721012ce8fbbebae82e4dbfc1ef4

- doc:  add JSON acronym.  Reported-by: torsten(dot)grust(at)gmail(dot)com Discussion:
  https://postgr.es/m/20171024201849.1488.71071@wrigleys.postgresql.org
  https://git.postgresql.org/pg/commitdiff/ca454b9bd34c75995eda4d07c9858f7c22890c2b

- C comment:  fix "the the" mentions in C comments.  Reported-by: Christoph
  Dreis Discussion:
  https://postgr.es/m/007e01d3519e$2734ca10$759e5e30$@freenet.de Author:
  Christoph Dreis
  https://git.postgresql.org/pg/commitdiff/bdb70c12b3a2e69eec6e51411df60d9f43ecc841

- docs:  replace dblink() mention with foreign data mention.  Reported-by:
  steven(dot)winfield(at)cantabcapital(dot)com Discussion:
  https://postgr.es/m/20171031105039.17183.850@wrigleys.postgresql.org
  https://git.postgresql.org/pg/commitdiff/255f14183ac7bc6a83a5bb00d67d5ac7e8b645f1

Robert Haas pushed:

- Fix comment.  RELATION_IS_OTHER_TEMP is tested in the caller, not here.
  Discussion: http://postgr.es/m/5A5438E4.3090709@lab.ntt.co.jp
  https://git.postgresql.org/pg/commitdiff/63008b19ee67270231694500832b031868d34428

- Don't allow VACUUM VERBOSE ANALYZE VERBOSE.  There are plans to extend the
  syntax for ANALYZE, so we need to break the link between VacuumStmt and
  AnalyzeStmt.  But apart from that, the syntax above is undocumented and, if
  discovered by users, might give the impression that the VERBOSE option for
  VACUUM differs from the verbose option from ANALYZE, which it does not.
  Nathan Bossart, reviewed by Michael Paquier and Masahiko Sawada Discussion:
  http://postgr.es/m/D3FC73E2-9B1A-4DB4-8180-55F57D116B4E@amazon.com
  https://git.postgresql.org/pg/commitdiff/921059bd66c7fb1230c705d3b1a65940800c4cbb

- Add missing "return" statement to accumulate_append_subpath.  Without this,
  Parallel Append can end up with extra children.  Report by Rajkumar
  Raghuwanshi.  Fix by Amit Khandekar.  Brown paper bag bug by me.  Discussion:
  http://postgr.es/m/CAKcux6mBF-NiddyEe9LwymoUC5+wh8bQJ=uk2gGkOE+L8cv=LA@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/2fd58096f02777c38edb392f78cb5b4ebd90e9d2

Peter Eisentraut pushed:

- Fix ssl tests for when tls-server-end-point is not supported.  Add a function
  to TestLib that allows us to check pg_config.h and then decide the expected
  test outcome based on that.  Author: Michael Paquier
  <michael(dot)paquier(at)gmail(dot)com>
  https://git.postgresql.org/pg/commitdiff/c3d41ccf5931a2e587d114d9886717df76459a9d

- Update portal-related memory context names and API.  Rename PortalMemory to
  TopPortalContext, to avoid confusion with PortalContext and align naming with
  similar top-level memory contexts.  Rename PortalData's "heap" field to
  portalContext.  The "heap" naming seems quite antiquated and confusing.  Also
  get rid of the PortalGetHeapMemory() macro and access the field directly,
  which we do for other portal fields, so this abstraction doesn't buy anything.
  Reviewed-by: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> Reviewed-by:
  Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
  https://git.postgresql.org/pg/commitdiff/0f7c49e85518dd846ccd0a044d49a922b9132983

- Remove PortalGetQueryDesc().  After having gotten rid of
  PortalGetHeapMemory(), there seems little reason to keep one Portal access
  macro around that offers no actual abstraction and isn't consistently used
  anyway.  Reviewed-by: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
  Reviewed-by: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
  https://git.postgresql.org/pg/commitdiff/a77dd53f3089a3d6bf74966bfd3ab7e27537183b

- Give more accurate error message for dropping pinned portal.  The previous
  code gave the same error message for attempting to drop pinned and active
  portals, but those are separate states, so give separate error messages.
  https://git.postgresql.org/pg/commitdiff/acc67ffd0a8c728b928958e75b76ee544b64c2d8

- Move portal pinning from PL/pgSQL to SPI.  PL/pgSQL "pins" internally
  generated (unnamed) portals so that user code cannot close them by guessing
  their names.  This logic is also useful in other languages and really for any
  code.  So move that logic into SPI.  An unnamed portal obtained through
  SPI_cursor_open() and related functions is now automatically pinned, and
  SPI_cursor_close() automatically unpins a portal that is pinned.  In the core
  distribution, this affects PL/Perl and PL/Python, preventing users from
  manually closing cursors created by spi_query and plpy.cursor, respectively.
  (PL/Tcl does not currently offer any cursor functionality.) Reviewed-by:
  Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
  https://git.postgresql.org/pg/commitdiff/b3617cdfbba1b5381e9d1c6bc0839500e8eb7273

- Revert "Move portal pinning from PL/pgSQL to SPI".  This reverts commit
  b3617cdfbba1b5381e9d1c6bc0839500e8eb7273.  This broke returning unnamed
  cursors from PL/pgSQL functions.  Apparently, there are no test cases for
  this.
  https://git.postgresql.org/pg/commitdiff/b48b2f8793ef256d19274b4ef6ff587fd47ab553

- Add tests for PL/pgSQL returning unnamed portals as refcursor.  Existing tests
  only covered returning explicitly named portals as refcursor.  The unnamed
  cursor case was recently broken without a test failing.
  https://git.postgresql.org/pg/commitdiff/511585417079b7d52211e09b20de0e0981b6eaa6

- Use portal pinning in PL/Perl and PL/Python.  PL/pgSQL "pins" internally
  generated portals so that user code cannot close them by guessing their names.
  Add this functionality to PL/Perl and PL/Python as well, preventing users from
  manually closing cursors created by spi_query and plpy.cursor, respectively.
  (PL/Tcl does not currently offer any cursor functionality.)
  https://git.postgresql.org/pg/commitdiff/70d6226e4fba26765877fc3c2ec6c468d3ff4084

- Fix Latin spelling.  "c.f." should be "cf.".
  https://git.postgresql.org/pg/commitdiff/9e945f862633882cae3183d465f321bd8dd591f9

- Refactor subscription tests to use PostgresNode's wait_for_catchup.  This was
  nearly the same code.  Extend wait_for_catchup to allow waiting for
  pg_current_wal_lsn() and use that in the subscription tests.  Also change one
  use in the pg_rewind tests to use this.  Also remove some broken code in
  wait_for_catchup and wait_for_slot_catchup.  The error message in case the
  waiting failed wanted to show the current LSN, but the way it was written
  never worked.  So since nobody ever cared, just remove it.  Reviewed-by:
  Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
  https://git.postgresql.org/pg/commitdiff/bbd3363e128daec0e70952c1bb2f12ab1f6f1292

Andrew Dunstan pushed:

- Implement TZH and TZM timestamp format patterns.  These are compatible with
  Oracle and required for the datetime template language for jsonpath in an
  upcoming patch.  Nikita Glukhov and Andrew Dunstan, reviewed by Pavel Stehule.
  https://git.postgresql.org/pg/commitdiff/11b623dd0a2c385719ebbbdd42dd4ec395dcdc9d

Álvaro Herrera pushed:

- Change some bogus PageGetLSN calls to BufferGetLSNAtomic.  As
  src/backend/access/transam/README says, PageGetLSN may only be called by
  processes holding either exclusive lock on buffer, or a shared lock on buffer
  plus buffer header lock.  Therefore any place that only holds a shared buffer
  lock must use BufferGetLSNAtomic instead of PageGetLSN, which internally
  obtains buffer header lock prior to reading the LSN.  A few callsites failed
  to comply with this rule.  This was detected by running all tests under a new
  (not committed) assertion that verifies PageGetLSN locking contract.  All but
  one of the callsites that failed the assertion are fixed by this patch.
  Remaining callsites were inspected manually and determined not to need any
  change.  The exception (unfixed callsite) is in TestForOldSnapshot, which only
  has a Page argument, making it impossible to access the corresponding Buffer
  from it.  Fixing that seems a much larger patch that will have to be done
  separately; and that's just as well, since it was only introduced in 9.6 and
  other bugs are much older.  Some of these bugs are ancient; backpatch all the
  way back to 9.3.  Authors: Jacob Champion, Asim Praveen, Ashwin Agrawal
  Reviewed-by: Michaël Paquier Discussion:
  https://postgr.es/m/CABAq_6GXgQDVu3u12mK9O5Xt5abBZWQ0V40LZCE+oUf95XyNFg@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/272c2ab9fd0a604e3200030b1ea26fd464c44935

- Remove hard-coded schema knowledge about pg_attribute from genbki.pl.  Add the
  ability to label a column's default value in the catalog header, and implement
  this for pg_attribute.  A new function in Catalog.pm is used to fill in a
  tuple with defaults.  The build process will complain loudly if a catalog
  entry is incomplete, Commit 8137f2c3232 labeled variable length columns for
  the C preprocessor.  Expose that label to genbki.pl so we can exclude those
  columns from schema macros in a general fashion. Also, format schema macro
  entries according to their types.  This means slightly less code maintenance,
  but more importantly it's a proving ground for mechanisms intended to be used
  in later commits.  While at it, I (Álvaro) couldn't resist making some changes
  in genbki.pl: rename some functions to actually indicate their purpose instead
  of actively misleading onlookers; and don't iterate on the whole of pg_type to
  find the entry for each catalog row, using a hash instead of an array.
  Author: John Naylor, some changes by Álvaro Herrera Discussion:
  https://postgr.es/m/CAJVSVGVJHwD8sfDfZW9TbCHWKf=C1YDRM-rF=2JenRU_y+VcFg@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/49c784ece766781250224a371be14af71e7eda93

Andres Freund pushed:

- Expression evaluation based aggregate transition invocation.  Previously
  aggregate transition and combination functions were invoked by special case
  code in nodeAgg.c, evaluating input and filters separately using the
  expression evaluation machinery. That turns out to not be great for
  performance for several reasons: - repeated expression evaluations have some
  cost - the transition functions invocations are poorly predicted, as commonly
  there are multiple aggregates in a query, resulting in the same call-stack
  invoking different functions.  - filter and input computation had to be done
  separately - the special case code made it hard to implement JITing of the
  whole transition function invocation Address this by building one large
  expression that computes input, evaluates filters, and invokes transition
  functions.  This leads to moderate speedups in queries bottlenecked by
  aggregate computations, and enables large speedups for similar cases once
  JITing is done.  There's potential for further improvement: - It'd be nice if
  we could simplify the somewhat expensive aggstate->all_pergroups lookups.  -
  right now there's still an advance_transition_function invocation in
  nodeAgg.c, leading to some code duplication.  Author: Andres Freund
  Discussion:
  https://postgr.es/m/20170901064131.tazjxwus3k2w3ybh@alap3.anarazel.de
  https://git.postgresql.org/pg/commitdiff/69c3936a1499b772a749ae629fc59b2d72722332

Teodor Sigaev pushed:

- Fix allowing of leading zero on exponents in pgbench test results.  Commit
  bc7fa0c15c590ddf4872e426abd76c2634f22aca accidentally lost fixes of
  0aa1d489ea756b96b6d5573692ae9cd5d143c2a5 commit.  Thanks to Thomas Munro
  https://git.postgresql.org/pg/commitdiff/d16c2de6244f3b71c0c77a3d63905227fdc78428

- Improve scripting language in pgbench.  Added: - variable now might contain
  integer, double, boolean and null values - functions ln, exp - logical
  AND/OR/NOT - bitwise AND/OR/NOT/XOR - bit right/left shift - comparison
  operators - IS [NOT] (NULL|TRUE|FALSE) - conditional choice (in form of
  when/case/then) New operations and functions allow to implement more
  complicated test scenario.  Author: Fabien Coelho with minor editorization by
  me Reviewed-By: Pavel Stehule, Jeevan Ladhe, me Discussion:
  https://www.postgresql.org/message-id/flat/alpine(dot)DEB(dot)2(dot)10(dot)1604030742390(dot)31618(at)sto
  https://git.postgresql.org/pg/commitdiff/bc7fa0c15c590ddf4872e426abd76c2634f22aca

- Fix behavior of ~> (cube, int) operator.  ~> (cube, int) operator was
  especially designed for knn-gist search.  However, it appears that knn-gist
  search can't work correctly with current behavior of this operator when
  dataset contains cubes of variable dimensionality. In this case, the same
  value of second operator argument can point to different dimension depending
  on dimensionality of particular cube.  Such behavior is incompatible with gist
  indexing of cubes, and knn-gist doesn't work correctly for it.  This patch
  changes behavior of ~> (cube, int) operator by introducing dimension numbering
  where value of second argument unambiguously identifies number of dimension.
  With new behavior, this operator can be correctly supported by knn-gist.
  Relevant changes to cube operator class are also included.  Backpatch to v9.6
  where operator was introduced.  Since behavior of ~> (cube, int) operator is
  changed, depending entities must be refreshed after upgrade. Such as,
  expression indexes using this operator must be reindexed, materialized views
  must be rebuilt, stored procedures and client code must be revised to
  correctly use new behavior.  That should be mentioned in release notes.
  Noticed by: Tomas Vondra Author: Alexander Korotkov Reviewed by: Tomas Vondra,
  Andrey Borodin Discussion:
  https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292(at)2ndquadrant(dot)com
  https://git.postgresql.org/pg/commitdiff/563a053bdd4b91c5e5560f4bf91220e562326f7d

- Allow negative coordinate for ~> (cube, int) operator.  ~> (cube, int)
  operator was especially designed for knn-gist search.  However, knn-gist
  supports only ascending ordering of results. Nevertheless it would be useful
  to support descending ordering by ~> (cube, int) operator.  We provide
  workaround for that: negative coordinate give us inversed value of
  corresponding cube bound.  Therefore, knn search using negative coordinate
  gives us an effect of descending ordering by cube bound.  Author: Alexander
  Korotkov Reviewed by: Tomas Vondra, Andrey Borodin Discussion:
  https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292(at)2ndquadrant(dot)com
  https://git.postgresql.org/pg/commitdiff/f50c80dbb17efa39c169f6c510e9464486ff5edc

Michael Meskes pushed:

- Fix parsing of compatibility mode argument.  Patch by Ashutosh Sharma
  <ashu(dot)coek88(at)gmail(dot)com>
  https://git.postgresql.org/pg/commitdiff/ca4587f3f94f5c33da6543535f666a9f20f3ef33

- Cope with indicator arrays that do not have the correct length.  Patch by:
  "Rader, David" <davidr(at)openscg(dot)com>
  https://git.postgresql.org/pg/commitdiff/649aeb123f73e69cf78c52b534c15c51a229d63d

== Pending Patches ==

Alexander Korotkov sent in another revision of a patch to implement incremental
sort.

Shubham Barai sent in three more revisions of a patch to implement predicate
locking for GiST indexes.

Haribabu Kommi sent in a patch to add a new libpq API, PQeffectiveconninfo,
which is similar to PQconninfo. It provides the effectively used connection
options in the current connection. An accompanying patch uses the API to add
effective an conninfo column to pg_stat_wal_receiver.

Catalin Iacob sent in a patch to document huge_pages better.

Álvaro Herrera sent in three more revisions of a patch to implement local
indexes on partitioned tables.

Michaël Paquier sent in a patch to clarify the hostaddrs part of the libpq
documentation.

Masahiko Sawada sent in another revision of a patch to fix an bug in the slot
error callback.

Haribabu Kommi sent in another revision of a patch to implement pluggable
storage.

Peter Eisentraut sent in a patch to add a prokind column, replacing proisagg and
proiswindow and update pg_proc.h with this change.

Andres Freund sent in a patch to implement grouping equality using expressions,
a step towards JITing same.

Chapman Flack and Fabien COELHO traded patches to enable setting random seeds in
pgbench.

Alexander Korotkov sent in two more revisions of a patch to implement 64-bit
XIDs.

Ildar Musin and Fabien COELHO traded patches to implement a general purpose
hashing function in pgbench.

David Rowley sent in another revision of a patch to implement runtime partition
pruning.

Yuqi Gu sent in a patch to make crc32 more efficient on the ARM64 architecture.

Aleksandr Parfenov sent in another revision of a patch to make full text search
configuration more flexible.

Fabien COELHO sent in a patch to fix an issue with pgbench on Windows.

Fabien COELHO sent in another revision of a patch to enable pgbench to store
query results as variables.

Konstantin Knizhnik sent in another revision of a patch to improve non-injective
functional indexes.

Fabien COELHO sent in a patch to fix a typo in a pgbench TAP test.

Konstantin Knizhnik sent in another revision of a patch to implement AS OF
queries.

Nikita Glukhov sent in another revision of a patch to implement JSONPATH.

Nikita Glukhov sent in a patch to implement JSON functions per SQL:2016.

Nathan Bossart sent in another revision of a patch to add a NOWAIT option to
VACUUM and add a parenthesized option syntax to ANALYZE.

Julian Markwort sent in another revision of a patch to enable pg_stat_statements
to track poor plans.

Haribabu Kommi sent in two revisions of a patch to ensure that PQhost returns
correct host details.

Fabien COELHO sent in another revision of a patch to add \if to pgbench.

Jeff Davis sent in another revision of a patch to implement range merge joins.

Daniel Gustafsson sent in two more revisions of a patch to use strcmp() instead
of pg_strcasecmp() for identifier matching and avoid silently changing
volatility in CREATE FUNCTION.

Amit Khandekar sent in another revision of a patch to make updates to
partition keys that would have the effect of moving tuples to another partition
Just Work™.

Nikita Glukhov sent in another revision of a patch to implement JSON_TABLE.

Etsuro Fujita sent in another revision of a patch to allow pushing more UPDATE
quals to the PostgreSQL FDW.

Kyotaro HORIGUCHI sent in another revision of a patch to fix a WAL logging
problem.

Kyotaro HORIGUCHI sent in another revision of a patch to implement asynchronous
execution in general and in the PostgreSQL FDW in particular.

Jeevan Chalke sent in another revision of a patch to implement partition-wise
aggregation/grouping.

Konstantin Knizhnik sent in another revision of a patch to optimize secondary
indexes.

Kyotaro HORIGUCHI sent in another revision of a patch to allow limiting the
resources logical replication uses by adding a WAL relief valve for replication
slots, a monitoring aid for max_replication_slots, TAP tests for the slot
limiting feature, and document documentation for same.

Álvaro Herrera sent in another revision of a patch to implement unique indexes
on partitioned tables.

Tsutomu Yamada sent in a patch to change estimate_path_cost_size in postgres_fdw
to refer to foreignrel instead of baserel.

Tsutomu Yamada sent in a patch to add queryEnv to ExplainOneQuery_hook.

Stephen Frost sent in two more revisions of a patch to remove the redundant
IndexTupleDSize macro.

Christian Rossow sent in a patch to implement bitwise logical operations
implementation (xor / and / or / not) for bytea.

Amit Langote and David Rowley traded patches to speed up partition pruning.

Thomas Munro sent in another revision of a patch to add plan count and time to
pg_stat_statements.

Vaishnavi Prabakaran sent in another revision of a patch to add batch/pipelining
support to libpq.

Michaël Paquier sent in a patch to ensure that pg_get_functiondef remembers all
GUC_LIST_INPUT GUCs.

Michaël Paquier sent in a patch to refactor the syscache routines to get
attribute name, extend lookup routines for FDW and foreign server with NULL
handling, refactor routines for subscription and publication lookups, and
eliminate user-visible cache lookup errors for objaddr SQL functions.

Edmund Horner sent in another revision of a patch to add tab completion to
SELECT in psql.

Amul Sul sent in another revision of a patch to see to it that when a tuple is
being moved to another partition, the ip_blkid in the tuple header is set to
InvalidBlockNumber and add isolation tests for same.

Konstantin Knizhnik sent in another revision of a patch to auto-prepare.

Artur Zakirov sent in a patch to fix a bug in to_timestamp() where it would,
under some circumstances, ignore a '-' character it should have taken into
account.

Anthony Bykov sent in another revision of a patch to implement JSONB transforms
for PL/PythonU.

Etsuro Fujita sent in another revision of a patch to add an eqpath for
foreignjoin.

Robert Haas sent in a patch to sort the epq path if needed.

Álvaro Herrera sent in another revision of a patch to implement foreign key
arrays.

Tomas Vondra sent in another revision of a patch to implement multivariate
histograms and MCV lists.

Anthony Bykov sent in another revision of a patch to implement transforms for
JSONB for PL/Perl.

Ildar Musin sent in a patch to add random_zipfian function to the paragraph in
pgbench documentation about random functions parameterization.

Curt Tilmes sent in a patch to find additional connection service files in
a newly invented pg_service.conf.d directory.

John Naylor sent in two more revisions of a patch to refactor how bootstrap data
is stored in source and handled.

Haribabu Kommi sent in a patch to define a previously undefined behavior when
the PQHost() connect string contains both host and hostaddr types.



Responses

pgsql-announce by date

Next:From: David FetterDate: 2018-01-15 15:23:49
Subject: Re: == PostgreSQL Weekly News - January 14 2018 ==
Previous:From: Monica Real AmoresDate: 2018-01-11 14:48:41
Subject: pglogical 2.1.1 Now Available

pgsql-www by date

Next:From: David FetterDate: 2018-01-15 15:23:49
Subject: Re: == PostgreSQL Weekly News - January 14 2018 ==
Previous:From: Joe ConwayDate: 2018-01-12 23:18:52
Subject: Re: request login for webpage...

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group