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

== PostgreSQL Weekly News - January 22 2017 ==

From: David Fetter <david(at)fetter(dot)org>
To: PostgreSQL Announce <pgsql-announce(at)postgresql(dot)org>
Subject: == PostgreSQL Weekly News - January 22 2017 ==
Date: 2017-01-22 23:24:24
Message-ID: 20170122232424.GA6120@fetter.org (view raw or whole thread)
Thread:
Lists: pgsql-announce
== PostgreSQL Weekly News - January 22 2017 ==

== PostgreSQL Jobs for January ==

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

== PostgreSQL Local ==

PGConf India 2017 will be on March 2-3, 2017 in Bengaluru, Karnataka.
http://pgconf.in/

PostgreSQL(at)SCaLE will take place on March 2-3, 2017, at Pasadena Convention
Center, as part of SCaLE 15X.
http://www.socallinuxexpo.org/scale/15x/

PgConf.Russia 2017 will take place on 15-17 March 2017 in Moscow.
https://pgconf.ru/en

PGDay Asia 2017 will be held March 17-18 in Singapore.
http://tinyurl.com/pgDay-Asia-2017-Cfp

Nordic PGDay 2017 will be held in Stockholm, Sweden, at the Sheraton
Hotel, on March 21, 2017.
https://2017.nordicpgday.org/

pgDay Paris 2017 will be held in Paris, France on March 23, 2017.
http://2017.pgday.paris/

PGConf US 2017 CfP will be on March 28-31 in Jersey City, New Jersey.
http://www.pgconf.us/2017/

PGCon 2017 will take place in Ottawa on 23-26 May.  Proposals are due by
19 Jan 2017.
http://www.pgcon.org/2017/papers.php

== PostgreSQL in the News ==

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

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

Submit news and announcements by Sunday at 3:00pm Pacific time.
Please send English language ones to david(at)fetter(dot)org, German language
to pwn(at)pgug(dot)de, Italian language to pwn(at)itpug(dot)org(dot)

== Applied Patches ==

Fujii Masao pushed:

- Fix typos in comments.  Masahiko Sawada
  http://git.postgresql.org/pg/commitdiff/8fa6019b405f9d39539a77c6f5f11fe640ddf955

- Fix an assertion failure related to an exclusive backup.  Previously multiple
  sessions could execute pg_start_backup() and pg_stop_backup() to start and
  stop an exclusive backup at the same time.  This could trigger the assertion
  failure of "FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)".  This
  happend because, even while pg_start_backup() was starting an exclusive
  backup, other session could run pg_stop_backup() concurrently and mark the
  backup as not-in-progress unconditionally.  This patch introduces
  ExclusiveBackupState indicating the state of an exclusive backup. This state
  is used to ensure that there is only one session running pg_start_backup() or
  pg_stop_backup() at the same time, to avoid the assertion failure.  Back-patch
  to all supported versions.  Author: Michael Paquier Reviewed-By: Kyotaro
  Horiguchi and me Reported-By: Andreas Seltenreich Discussion:
  <87mvktojme(dot)fsf(at)credativ(dot)de>
  http://git.postgresql.org/pg/commitdiff/974ece58bbb3c0ef185a9d44b1cedae51cd56b04

- Add description of temporary column into pg_replication_slots doc.  Ayumi
  Ishii
  http://git.postgresql.org/pg/commitdiff/954737095061e5b5f1d87fb8cc43f7f8afff64c6

Magnus Hagander pushed:

- Make pg_basebackup use temporary replication slots.  Temporary replication
  slots will be used by default when wal streaming is used and no slot name is
  specified with -S. If a slot name is specified, then a permanent slot with
  that name is used. If --no-slot is specified, then no permanent or temporary
  slot will be used.  Temporary slots are only used on 10.0 and newer, of
  course.
  http://git.postgresql.org/pg/commitdiff/e7b020f786bf3b344f81d70aa423525fd4f44dfa

- Fix incorrect comparison due to bad merge.  Noted by Fujii Masao
  http://git.postgresql.org/pg/commitdiff/fcf708623e860b7a1efef11a5d5661900307b6fc

- Add compression support to pg_receivexlog.  Author: Michael Paquier, review
  and small changes by me
  http://git.postgresql.org/pg/commitdiff/cada1af31d769a6b607018d68894f2c879ff275f

- Implement array version of jsonb_delete and operator.  This makes it possible
  to delete multiple keys from a jsonb value by passing in an array of text
  values, which makes the operaiton much faster than individually deleting the
  keys (which would require copying the jsonb structure over and over again.
  Reviewed by Dmitry Dolgov and Michael Paquier
  http://git.postgresql.org/pg/commitdiff/d00ca333c338b40911e89939c3cc771025978595

Tom Lane pushed:

- Fix NULL pointer dereference in tuplesort.c.  Oversight in commit e94568ecc.
  This could cause a crash when an external datum tuplesort of a pass-by-value
  type required multiple passes.  Per report from Mithun Cy.  Peter Geoghegan
  Discussion:
  https://postgr.es/m/CAD__OujuhfWFULGFSt1fyHqUb8N-XafjJhudwt88V0Qs2o84qg(at)mail(dot)gmail(dot)com
  http://git.postgresql.org/pg/commitdiff/4e46c97fde42fa8ca57d29b9b47f2ebd11ab8105

- Fix check_srf_call_placement() to handle VALUES cases correctly.  INSERT ...
  VALUES with a single VALUES row is implemented quite differently from the
  general VALUES case.  A user-visible implication of that is that we accept
  SRFs in the single-row case, but not in the multi-row case.  That's a
  historical artifact no doubt, but in view of the lack of field complaints, I'm
  not excited about fixing it right now.  However, check_srf_call_placement()
  needs to know about this, first because it should throw an error in the
  unsupported case, and second because it should set p_hasTargetSRFs in the
  single-row case (because we treat that like a SELECT tlist).  That's an
  oversight in commit a4c35ea1c.  To fix, split EXPR_KIND_VALUES into two
  values.  So far as I can see, this is the only place where we need to
  distinguish the two cases at present; but there might be more later.  Patch by
  me, per report from Andres Freund.  Discussion:
  https://postgr.es/m/20170116081548(dot)zg63zltblwimpfgp(at)alap3(dot)anarazel(dot)de
  http://git.postgresql.org/pg/commitdiff/d43a619c60405ecda275ca9e3ac9ead242e20ecb

- Improve RLS planning by marking individual quals with security levels.  In an
  RLS query, we must ensure that security filter quals are evaluated before
  ordinary query quals, in case the latter contain "leaky" functions that could
  expose the contents of sensitive rows.  The original implementation of RLS
  planning ensured this by pushing the scan of a secured table into a sub-query
  that it marked as a security-barrier view.  Unfortunately this results in very
  inefficient plans in many cases, because the sub-query cannot be flattened and
  gets planned independently of the rest of the query.  To fix, drop the use of
  sub-queries to enforce RLS qual order, and instead mark each qual
  (RestrictInfo) with a security_level field establishing its priority for
  evaluation.  Quals must be evaluated in security_level order, except that
  "leakproof" quals can be allowed to go ahead of quals of lower security_level,
  if it's helpful to do so.  This has to be enforced within the ordering of any
  one list of quals to be evaluated at a table scan node, and we also have to
  ensure that quals are not chosen for early evaluation (i.e., use as an index
  qual or TID scan qual) if they're not allowed to go ahead of other quals at
  the scan node.  This is sufficient to fix the problem for RLS quals, since we
  only support RLS policies on simple tables and thus RLS quals will always
  exist at the table scan level only.  Eventually these qual ordering rules
  should be enforced for join quals as well, which would permit improving
  planning for explicit security-barrier views; but that's a task for another
  patch.  Note that FDWs would need to be aware of these rules --- and not, for
  example, send an insecure qual for remote execution --- but since we do not
  yet allow RLS policies on foreign tables, the case doesn't arise.  This will
  need to be addressed before we can allow such policies.  Patch by me, reviewed
  by Stephen Frost and Dean Rasheed.  Discussion:
  https://postgr.es/m/8185(dot)1477432701(at)sss(dot)pgh(dot)pa(dot)us
  http://git.postgresql.org/pg/commitdiff/215b43cdc8d6b4a1700886a39df1ee735cb0274d

- Avoid conflicts with collation aliases generated by stripping.  This resulted
  in failures depending on the order of "locale -a" output.  The original coding
  in initdb sorted the results, but that should be unnecessary as long as
  "locale -a" doesn't print duplicate names.  The original entries will then all
  be non-dups, and while we might generate duplicate aliases by stripping, they
  should be for different encodings and thus not conflict.  Even if the latter
  assumption fails somehow, it won't be fatal because we're using if_not_exists
  mode for the aliases.  Discussion:
  https://postgr.es/m/26116.1484751196%40sss.pgh.pa.us
  http://git.postgresql.org/pg/commitdiff/0333a7340054c3356940759b1ab2391eed572171

- Disable transforms that replaced AT TIME ZONE with RelabelType.  These
  resulted in wrong answers if the relabeled argument could be matched to an
  index column, as shown in bug #14504 from Evgeniy Kozlov.  We might be able to
  resurrect these optimizations by adjusting the planner's treatment of
  RelabelType, or by adjusting btree's rules for selecting comparison functions,
  but either solution will take careful analysis and does not sound like a fit
  candidate for backpatching.  I left the catalog infrastructure in place and
  just reduced the transform functions to always-return-NULL.  This would be
  necessary anyway in the back branches, and it doesn't seem important to be
  more invasive in HEAD.  Bug introduced by commit b8a18ad48.  Back-patch to 9.5
  where that came in.  Report:
  https://postgr.es/m/20170118144828(dot)1432(dot)52823(at)wrigleys(dot)postgresql(dot)org
  Discussion: https://postgr.es/m/18771(dot)1484759439(at)sss(dot)pgh(dot)pa(dot)us
  http://git.postgresql.org/pg/commitdiff/c22ecc6562aac895f0f0529707d7bdb460fd2a49

- Reset the proper GUC in create_index test.  Thinko in commit a4523c5aa.  It
  doesn't really affect anything at present, but it would be a problem if any
  tests added later in this file ought to get index-only-scan plans.
  Back-patch, like the previous commit, just to avoid surprises in case we add
  such a test and then back-patch it.  Nikita Glukhov Discussion:
  https://postgr.es/m/8b70135d-ad38-bdd8-ac92-71e2b3c273cf(at)postgrespro(dot)ru
  http://git.postgresql.org/pg/commitdiff/1586317c3f57e619e0cde674c6da406f9d73aaff

- Doc: improve documentation of new SRF-in-tlist behavior.  Correct a
  misstatement about how things used to work: we did allow nested SRFs before,
  as long as no function had more than one set-returning input.  Also, attempt
  to document the fact that the new implementation changes the behavior for SRFs
  within conditional constructs (eg CASE): the conditional construct no longer
  gates whether the SRF is run, and thus cannot affect the number of rows
  emitted.  We might want to change this behavior, but first it behooves us to
  see if we can explain it.  Minor other wordsmithing on what I wrote yesterday,
  too.  Discussion:
  https://postgr.es/m/20170118214702(dot)54b2mdbxce5piwv5(at)alap3(dot)anarazel(dot)de
  http://git.postgresql.org/pg/commitdiff/f13a1277aa2df301583c6db9c2989d2e9d7f6483

- Fix Assert failure induced by commit 215b43cdc.  I'd somehow talked myself
  into believing that set_append_rel_size doesn't need to worry about getting
  back an AND clause when it applies eval_const_expressions to the result of
  adjust_appendrel_attrs (that is, transposing the appendrel parent's
  restriction clauses for one child).  But that is nonsense, and Andreas
  Seltenreich's fuzz tester soon turned up a counterexample.  Put back the
  make_ands_implicit step that was there before, and add a regression test
  covering the case.  Report: https://postgr.es/m/878tq6vja6(dot)fsf(at)ansel(dot)ydns(dot)eu
  http://git.postgresql.org/pg/commitdiff/d479e37e3d20efad8b178e0f1e468c086a7519a8

- Avoid core dump for empty prepared statement in an aborted transaction.
  Brown-paper-bag bug in commit ab1f0c822: the old code here coped with null
  CachedPlanSource.raw_parse_tree, the new code not so much.  Per report from
  Dave Cramer.  No regression test, because our core testing infrastructure
  doesn't provide any easy way to exercise this path.  Fortunately, the JDBC
  crew test it regularly.  Discussion:
  https://postgr.es/m/CADK3HH+Ug3xCysKqw_dZOnaNnytZ1Rh5yP05hjO-e4NoyRxVvA(at)mail(dot)gmail(dot)com
  http://git.postgresql.org/pg/commitdiff/ba61a04bc7fefeee03416d9911eb825c4897c223

- Allow backslash line continuations in pgbench's meta commands.  A pgbench meta
  command can now be continued onto additional line(s) of a script file by
  writing backslash-return.  The continuation marker is equivalent to white
  space in that it separates tokens.  Eventually it'd be nice to have the same
  thing in psql, but that will be a much larger project.  Fabien Coelho,
  reviewed by Rafia Sabih Discussion:
  https://postgr.es/m/alpine(dot)DEB(dot)2(dot)20(dot)1610031049310(dot)19411(at)lancre
  http://git.postgresql.org/pg/commitdiff/cdc2a70470bdbe3663dc464deb753d6d931bba61

- Try to fix non-MSVC Windows builds in the wake of logical replication.
  pgoutput evidently needs to be built without -DBUILDING_DLL.  (It seems like a
  pretty bad idea that these makefiles need to know exactly where all the shlibs
  are in the tree, or maybe what's bad is putting them under src/backend/.  But
  right now is not the time to redesign that.) Also, remove "override CPPFLAGS"
  in pgoutput's Makefile.  I don't think that that actually has any bad
  consequences, but it's certainly useless in a directory that has no .h files,
  and it might be contributing to the failure somehow.  Per buildfarm.
  http://git.postgresql.org/pg/commitdiff/0502e854640bd024f349c0df46b7dd6812b8c05c

- Fix cross-shlib linking in temporary installs on HPUX 10.  Turns out this has
  been broken for years and we'd not noticed.  The one case that was getting
  exercised in the buildfarm, or probably anywhere else, was postgres_fdw.sl's
  reference to libpq.sl; and it turns out that that was always going to libpq.sl
  in the actual installation directory not the temporary install.  We'd not
  noticed because the buildfarm script does "make install" before it tests
  contrib.  However, the recent addition of a logical-replication test to the
  core regression scripts resulted in trying to use libpqwalreceiver.sl before
  "make install" happens, and that failed for lack of finding libpq.sl, as shown
  by failures on buildfarm members gaur and pademelon.  There are two changes
  needed to fix it: the magic environment variable to specify shlib search path
  at runtime is SHLIB_PATH not LD_LIBRARY_PATH, and the shlib link command needs
  to specify the +s switch else the library will not honor SHLIB_PATH.  I'm not
  quite sure why buildfarm members anole and gharial (HPUX 11) didn't show the
  same failure.  Consulting man pages on the web says that HPUX 11 honors both
  LD_LIBRARY_PATH and SHLIB_PATH, which would explain half of it, and the rather
  confusing wording I've been able to find suggests that +s might effectively be
  the default in HPUX 11.  But it seems at least as likely that there's just a
  libpq.so installed in /usr/lib on that machine; as long as it's not too
  ancient, that would satisfy the test.  In any case I do not think this patch
  will break HPUX 11.  At the moment I don't see a need to back-patch this,
  since it only matters for testing purposes, not to mention that HPUX 10 is
  probably dead in the real world anyway.
  http://git.postgresql.org/pg/commitdiff/d2ab1176160e30543da1e48f7e0d17564852b693

- Remove no-longer-needed loop in ExecGather().  Coverity complained quite
  properly that commit ea15e1867 had introduced unreachable code into
  ExecGather(); to wit, it was no longer possible to iterate the final for-loop
  more or less than once.  So remove the for().  In passing, clean up a couple
  of comments, and make better use of a local variable.
  http://git.postgresql.org/pg/commitdiff/0a8b9d3b2c57028f7100078cd711370f396d5a81

- Relocate static function declarations to be after typedefs in jsonfuncs.c.
  Project style is to put things in this order, for the good and sufficient
  reason that you often need the typedefs in the function declarations.  There
  already was one function declaration that needed a typedef, which was randomly
  placed away from all the other static function declarations in consequence.
  And the submitted patch for better json_populate_record functionality jumped
  through even more hoops in order to preserve this bad idea.  This patch only
  moves lines from point A to point B, no other changes.
  http://git.postgresql.org/pg/commitdiff/90992e0e2f9fc4aa0f6402f0327604e5fef4630c

Peter Eisentraut pushed:

- doc: Update URL for Microsoft download site.
  http://git.postgresql.org/pg/commitdiff/6181c34da882544c4842e7442189a7ea1dd03032

- Rename C symbols for backend lo_ functions.  Rename the C symbols for lo_* to
  be_lo_*, so they don't conflict with libpq prototypes.  Reviewed-by: Pavel
  Stehule <pavel(dot)stehule(at)gmail(dot)com>
  http://git.postgresql.org/pg/commitdiff/6fc547960dbe0b8bd6cefae5ab7ec3605a5c46fc.

- Register missing money operators in system catalogs.  The operators money*int8,
  int8*money, and money/int8 were implemented in code but not registered in
  pg_operator or pg_proc.  Reviewed-by: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
  http://git.postgresql.org/pg/commitdiff/323b96aa34239b5a8fe773d614a6ee50d731a683.

- Remove unnecessary prototypes in loadable modules.  Reviewed-by: Pavel Stehule
  <pavel(dot)stehule(at)gmail(dot)com>
  http://git.postgresql.org/pg/commitdiff/5d7c9c906a0b888dcfd3b0a2f2170e1f5ca366c4

- Add more tests for money type.  Add tests for functions currently not covered
  at all.  Reviewed-by: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
  http://git.postgresql.org/pg/commitdiff/09e35315ccafb83c52da2e0fd6a0a9be410ce6a4

- Remove unnecessary include.  Between 6eeb95f0f56bb5e8a0a9328aeec04c9e6de87272
  and 7b1c2a0f2066672b24f6257ec9b8d78a1754f494, builtins.h contained additional
  prototypes that have now been moved elsewhere, so we don't need to include
  nodes/parsenodes.h anymore.  Fix some files that were relying on builtins.h
  implicitly pulling in some unrelated stuff they needed.  Reviewed-by: Pavel
  Stehule <pavel(dot)stehule(at)gmail(dot)com>
  http://git.postgresql.org/pg/commitdiff/30b9a4495a8ec1f20ba518b34d679c700eadab16

- Correct include file path.  Mistake in
  352a24a1f9d6f7d4abb1175bfd22acc358f43140, not clear why it worked for some
  before.
  http://git.postgresql.org/pg/commitdiff/063ef8308b148e3581ddb626fdb397f7a5a48303

- Generate fmgr prototypes automatically.  Gen_fmgrtab.pl creates a new file
  fmgrprotos.h, which contains prototypes for all functions registered in
  pg_proc.h.  This avoids having to manually maintain these prototypes across a
  random variety of header files.  It also automatically enforces a correct
  function signature, and since there are warnings about missing prototypes, it
  will detect functions that are defined but not registered in pg_proc.h (or
  otherwise used).  Reviewed-by: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
  http://git.postgresql.org/pg/commitdiff/352a24a1f9d6f7d4abb1175bfd22acc358f43140

- initdb: Fix for mixed-case superuser names.  The previous coding did not
  properly quote the user name before casting it to regrole.  To avoid all that,
  just pass in BOOTSTRAP_SUPERUSERID numerically.  Also fix one place where the
  BOOTSTRAP_SUPERUSERID was hardcoded as 10.
  http://git.postgresql.org/pg/commitdiff/8b0fec93ecc788c8d8b329d41ab795712d8dcc5a

- Add function to import operating system collations.  Move this logic out of
  initdb into a user-callable function.  This simplifies the code and makes it
  possible to update the standard collations later on if additional operating
  system collations appear.  Reviewed-by: Andres Freund <andres(at)anarazel(dot)de>
  Reviewed-by: Euler Taveira <euler(at)timbira(dot)com(dot)br>
  http://git.postgresql.org/pg/commitdiff/aa17c06fb58533d09c79c68a4d34a6f56687ee38

- Bump catversion.
  http://git.postgresql.org/pg/commitdiff/e4c27f5befbfc80a1bf96fc93256dce08b148238

- Paper over pg_upgrade test failure.  The publication test didn't drop all the
  publications it was creating when it was probably intending to do that.  There
  is still a bug with dependency tracking in there, but this should at least
  quiet down the build farm.
  http://git.postgresql.org/pg/commitdiff/6c488ea13634897df5f9b5769eb26bbc3d926ce0

- Move some things from builtins.h to new header files.  This avoids that
  builtins.h has to include additional header files.
  http://git.postgresql.org/pg/commitdiff/f21a563d25dbae153937aec062161184189478b8

- Logical replication.  - Add PUBLICATION catalogs and DDL.  - Add SUBSCRIPTION
  catalog and DDL.  - Define logical replication protocol and output plugin.  -
  Add logical replication workers.  From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
  Reviewed-by: Steve Singer <steve(at)ssinger(dot)info> Reviewed-by: Andres Freund
  <andres(at)anarazel(dot)de> Reviewed-by: Erik Rijkers <er(at)xs4all(dot)nl> Reviewed-by:
  Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
  http://git.postgresql.org/pg/commitdiff/665d1fad99e7b11678b0d5fa24d2898424243cd6

- Add more includes so header files are self-contained.
  http://git.postgresql.org/pg/commitdiff/b48008676002895c284c9a7a3d4fc7210b58044d

- Add missing break.
  http://git.postgresql.org/pg/commitdiff/8f164e1eeaf31438f6706ed45efee607a2c7a21b

Álvaro Herrera pushed:

- Fix typo.
  http://git.postgresql.org/pg/commitdiff/dda7c34555ca3696fd2a8b93d9aabad333c6cb4e

- Fix typo.
  http://git.postgresql.org/pg/commitdiff/593c75d5c38a47096f11e318cdb3321a5780753f

- Remove dead code in bootstrap.  The bootstrap scanner/parser contains code to
  parse floating point values, but this is not exercised anywhere, so remove it.
  Reviewed-by: Jim Nasby Discussion:
  https://postgr.es/m/20170110051119(dot)b5h7i3z5qagy35rb(at)alvherre(dot)pgsql
  http://git.postgresql.org/pg/commitdiff/193a7d791ebe2adf32b36d5538e4602a90c3e0fb

- Make messages mentioning type names more uniform.  This avoids additional
  translatable strings for each distinct type, as well as making our quoting
  style around type names more consistent (namely, that we don't quote type
  names).  This continues what started as f402b9950120.  Discussion:
  https://postgr.es/m/20160401170642(dot)GA57509(at)alvherre(dot)pgsql
  http://git.postgresql.org/pg/commitdiff/9a34123bc315e55b33038464422ef1cd2b67dab2

- Change some test macros to return true booleans.  These macros work fine when
  they are used directly in an "if" test or similar, but as soon as the return
  values are assigned to boolean variables (or passed as boolean arguments to
  some function), they become bugs, hopefully caught by compiler warnings.  To
  avoid future problems, fix the definitions so that they return actual
  booleans.  To further minimize the risk that somebody uses them in
  back-patched fixes that only work correctly in branches starting from the
  current master and not in old ones, back-patch the change to supported
  branches as appropriate.  See also commit
  af4472bcb88ab36b9abbe7fd5858e570a65a2d1a, and the long discussion (and larger
  patch) in the thread mentioned in its commit message.  Discussion:
  https://postgr.es/m/18672(dot)1483022414(at)sss(dot)pgh(dot)pa(dot)us
  http://git.postgresql.org/pg/commitdiff/594e61a1de03ab93779e7e3d853edb7859d5c3cf

- Allow negative years in make_date to represent BC years.  There doesn't seem
  to be any reason not to allow negative years to be interpreted as BC, so do
  that.  The documentation is pretty vague on the details of this function, so
  nothing needs to change there.  Reported-by: Andy Abelisto, in bug #14446
  http://git.postgresql.org/pg/commitdiff/30bcebbdcf23eb8b78e553c4b3b5eb847410ef19

- Fix race condition in reading commit timestamps.  If a user requests the
  commit timestamp for a transaction old enough that its data is concurrently
  being truncated away by vacuum at just the right time, they would receive an
  ugly internal file-not-found error message from slru.c rather than the
  expected NULL return value.  In a primary server, the window for the race is
  very small: the lookup has to occur exactly between the two calls by vacuum,
  and there's not a lot that happens between them (mostly just a multixact
  truncate).  In a standby server, however, the window is larger because the
  truncation is executed as soon as the WAL record for it is replayed, but the
  advance of the oldest-Xid is not executed until the next checkpoint record.
  To fix in the primary, simply reverse the order of operations in
  vac_truncate_clog.  To fix in the standby, augment the WAL truncation record
  so that the standby is aware of the new oldest-XID value and can apply the
  update immediately.  WAL version bumped because of this.  No backpatch,
  because of the low importance of the bug and its rarity.  Author: Craig Ringer
  Reviewed-By: Petr Jelínek, Peter Eisentraut Discussion:
  https://postgr.es/m/CAMsr+YFhVtRQT1VAwC+WGbbxZZRzNou=N9Ed-FrCqkwQ8H8oJQ(at)mail(dot)gmail(dot)com
  http://git.postgresql.org/pg/commitdiff/8eace46d34ab6ac0d887aa4d3504bc4222c2e448

- tests: Use the right Perl operator.  We were using != to compare strings, for
  which "ne" is the right thing.  It's not clear why it works everywhere except
  on Pavan's machine, but it's clearly bogus anyway.  Author and reporter: Pavan
  Deolasee Discussion:
  https://postgr.es/m/CABOikdPhsHM+pX8skoEY1_T0OtKdO1udzUj4VCjU5VEt+bj4eA(at)mail(dot)gmail(dot)com
  http://git.postgresql.org/pg/commitdiff/a600ee9e3fcc43d4497d18d837f1e86148ca7580

- Record dependencies on owners for logical replication objects.  This was
  forgotten in 665d1fad99e7b11678b0d5fa24d2898424243cd6 and caused the whole
  buildfarm to become red for a little while.  Author: Petr Jelínek.  Also fix a
  typo in a nearby error message.
  http://git.postgresql.org/pg/commitdiff/50cf1c80e6be80cc620749824fe9e3cd7f6c118e

Robert Haas pushed:

- Factor out logic for computing number of parallel workers.  Forthcoming
  patches to allow other types of parallel scans will need this logic, or
  something like it.  Dilip Kumar
  http://git.postgresql.org/pg/commitdiff/716c7d4b242f0a64ad8ac4dc48c6fed6557ba12c

- Update information_schema queries and system views for new relkind.  The
  original table partitioning patch overlooked this.  Discussion:
  http://postgr.es/m/CAG1_KcDJiZB=L6yOUO_bVufj2q2851_xdkfhw0JdcD_2VtKssw(at)mail(dot)gmail(dot)com
  Keith Fiske and Amit Langote, adjusted by me.
  http://git.postgresql.org/pg/commitdiff/262e821deced47337d6d807515997567bb45fd7d

- Add some more tests for tuple routing.  Commit
  a25665088d812d08bb888e961f208eaebf522050 fixed some issues with how
  PartitionDispatch related code handled multi-level partitioned tables, but
  didn't add any tests.  Discussion:
  http://postgr.es/m/CA%2BTgmoZ86v1G%2Bzx9etMiSQaBBvYMKfU-iitqZArSh5z0n8Q4cA%40mail.gmail.com
  Amit Langote, per a complaint from me.
  http://git.postgresql.org/pg/commitdiff/d26fa4fd47ae5f09c214e954ae9cf8a890bd3c35

- Avoid use of DROP TABLE .. CASCADE in partitioning tests.  This isn't really
  guaranteed to always produce exactly the same output; the order can change
  from run to run.  See related cleanup in
  257d8157205a7be5f9799e8941b922521d678a25.
  http://git.postgresql.org/pg/commitdiff/e509e7f9e3c565043e1186f5a83122d71653d111

- Improve comment in hashsearch.c.  Typo fix from Mithun Cy; other improvements
  by me.
  http://git.postgresql.org/pg/commitdiff/e37360d5df240443bb6e997d26d54f59146283fc

- Fix failure to enforce partitioning contraint for internal partitions.  When a
  tuple is inherited into a partitioning root, no partition constraints need to
  be enforced; when it is inserted into a leaf, the parent's partitioning quals
  needed to be enforced.  The previous coding got both of those cases right.
  When a tuple is inserted into an intermediate level of the partitioning
  hierarchy (i.e. a table which is both a partition itself and in turn
  partitioned), it must enforce the partitioning qual inherited from its parent.
  That case got overlooked; repair.  Amit Langote
  http://git.postgresql.org/pg/commitdiff/39162b2030fb0a35a6bb28dc636b5a71b8df8d1c

- Fix RETURNING to work correctly with partition tuple routing.  In
  ExecInsert(), do not switch back to the root partitioned table ResultRelInfo
  until after we finish ExecProcessReturning(), so that RETURNING projection is
  done using the partition's descriptor.  For the projection to work correctly,
  we must initialize the same for each leaf partition during ModifyTableState
  initialization.  Amit Langote
  http://git.postgresql.org/pg/commitdiff/05bd889904e03479a7169b1c36e0e1db13fff7cb

- Fix some problems in check_new_partition_bound().  Account for the fact that
  the highest bound less than or equal to the upper bound might be either the
  lower or the upper bound of the overlapping partition, depending on whether
  the proposed partition completely contains the existing partition or merely
  overlaps it.  Also, we need not continue searching for even greater bound in
  partition_bound_bsearch() once we find the first bound that is *equal* to the
  probe, because we don't have duplicate datums.  That spends cycles needlessly.
  Amit Langote, per a report from Amul Sul.  Cosmetic changes by me.
  Discussion:
  http://postgr.es/m/CAAJ_b94XgbqVoXMyxxs63CaqWoMS1o2gpHiU0F7yGnJBnvDc_A%40mail.gmail.com
  http://git.postgresql.org/pg/commitdiff/8a8afe2f54c27dbb47df3853803158c5205d41ce

- Avoid some code duplication in map_partition_varattnos().  Code to map
  attribute numbers in map_partition_varattnos() duplicates what
  convert_tuples_by_name_map() does.  Avoid that.  Amit Langote, per a report
  from Álvaro Herrera.  Discussion:
  http://postgr.es/m/9ce97382-54c8-deb3-9ee9-a2ec271d866b%40lab.ntt.co.jp
  http://git.postgresql.org/pg/commitdiff/cc144155f7cdd51e19984f82da6625dc75de9fda

- Teach partitioning tests not to use DROP TABLE ... CASCADE.  This occasionally
  causes failures; the order in which the affected objects are listed is not
  100% consistent.  Amit Langote
  http://git.postgresql.org/pg/commitdiff/c3978149536a9c3fb837524407c58dec2b103c60

- Fix comparison logic in partition_bounds_equal for non-finite bounds.  If
  either bound is infinite, then we shouldn't even try to perform a comparison
  of the values themselves.  Rearrange the logic so that we don't.  Per
  buildfarm member skink and Tom Lane.
  http://git.postgresql.org/pg/commitdiff/6546ffb35db78365d9f0011d75d16625e6040437

- Avoid useless respawining the autovacuum launcher at high speed.  When (1)
  autovacuum = off and (2) there's at least one database with an XID age greater
  than autovacuum_freeze_max_age and (3) all tables in that database that need
  vacuuming are already being processed by a worker and (4) the autovacuum
  launcher is started, a kind of infinite loop occurs.  The launcher starts a
  worker and immediately exits.  The worker, finding no worker to do,
  immediately starts the launcher, supposedly so that the next database can be
  processed.  But because datfrozenxid for that database hasn't been advanced
  yet, the new worker gets put right back into the same database as the old one,
  where it once again starts the launcher and exits.  High-speed ping pong
  ensues.  There are several possible ways to break the cycle; this seems like
  the safest one.  Amit Khandekar (code) and Robert Haas (comments), reviewed by
  Álvaro Herrera.  Discussion:
  http://postgr.es/m/CAJ3gD9eWejf72HKquKSzax0r+epS=nAbQKNnykkMA0E8c+rMDg(at)mail(dot)gmail(dot)com
  http://git.postgresql.org/pg/commitdiff/c6a389792e08980e395055ac219303cf4357ba33

Andres Freund pushed:

- Move targetlist SRF handling from expression evaluation to new executor node.
  Evaluation of set returning functions (SRFs_ in the targetlist (like SELECT
  generate_series(1,5)) so far was done in the expression evaluation (i.e.
  ExecEvalExpr()) and projection (i.e. ExecProject/ExecTargetList) code.  This
  meant that most executor nodes performing projection, and most expression
  evaluation functions, had to deal with the possibility that an evaluated
  expression could return a set of return values.  That's bad because it leads
  to repeated code in a lot of places. It also, and that's my (Andres's)
  motivation, made it a lot harder to implement a more efficient way of doing
  expression evaluation.  To fix this, introduce a new executor node
  (ProjectSet) that can evaluate targetlists containing one or more SRFs. To
  avoid the complexity of the old way of handling nested expressions returning
  sets (e.g. having to pass up ExprDoneCond, and dealing with arguments to
  functions returning sets etc.), those SRFs can only be at the top level of the
  node's targetlist.  The planner makes sure (via split_pathtarget_at_srfs())
  that SRF evaluation is only necessary in ProjectSet nodes and that SRFs are
  only present at the top level of the node's targetlist. If there are nested
  SRFs the planner creates multiple stacked ProjectSet nodes.  The ProjectSet
  nodes always get input from an underlying node.  We also discussed and
  prototyped evaluating targetlist SRFs using ROWS FROM(), but that turned out
  to be more complicated than we'd hoped.  While moving SRF evaluation to
  ProjectSet would allow to retain the old "least common multiple" behavior when
  multiple SRFs are present in one targetlist (i.e.  continue returning rows
  until all SRFs are at the end of their input at the same time), we decided to
  instead only return rows till all SRFs are exhausted, returning NULL for
  already exhausted ones.  We deemed the previous behavior to be too confusing,
  unexpected and actually not particularly useful.  As a side effect, the
  previously prohibited case of multiple set returning arguments to a function,
  is now allowed. Not because it's particularly desirable, but because it ends
  up working and there seems to be no argument for adding code to prohibit it.
  Currently the behavior for COALESCE and CASE containing SRFs has changed,
  returning multiple rows from the expression, even when the SRF containing
  "arm" of the expression is not evaluated. That's because the SRFs are
  evaluated in a separate ProjectSet node.  As that's quite confusing, we're
  likely to instead prohibit SRFs in those places.  But that's still being
  discussed, and the code would reside in places not touched here, so that's a
  task for later.  There's a lot of, now superfluous, code dealing with set
  return expressions around. But as the changes to get rid of those are verbose
  largely boring, it seems better for readability to keep the cleanup as a
  separate commit.  Author: Tom Lane and Andres Freund Discussion:
  https://postgr.es/m/20160822214023(dot)aaxz5l4igypowyri(at)alap3(dot)anarazel(dot)de
  http://git.postgresql.org/pg/commitdiff/69f4b9c85f168ae006929eec44fc44d569e846b9

- Adapt python regression tests to 69f4b9c85f16.  Hopefully this'll unbreak the
  buildfarm.
  http://git.postgresql.org/pg/commitdiff/8b07aee8c5d803801c00103f0d61e32356aaf29c

- Remove obsoleted code relating to targetlist SRF evaluation.  Since 69f4b9c
  plain expression evaluation (and thus normal projection) can't return sets of
  tuples anymore. Thus remove code dealing with that possibility.  This will
  require adjustments in external code using ExecEvalExpr()/ExecProject() - that
  should neither be hard nor very common.  Author: Andres Freund and Tom Lane
  Discussion:
  https://postgr.es/m/20160822214023(dot)aaxz5l4igypowyri(at)alap3(dot)anarazel(dot)de
  http://git.postgresql.org/pg/commitdiff/ea15e18677fc2eff3135023e27f69ed8821554ed

- Fix platform dependant regression output triggered by 69f4b9c85f16.  Due to
  the changed costing in that commit hash-aggregates started to be used, which
  results in big-endian vs. little-endian output differences.  Disable hash-aggs
  for those tests.  Author: Andres Freund, with input from Tom Lane Discussion:
  https://postgr.es/m/22891(dot)1484791792(at)sss(dot)pgh(dot)pa(dot)us
  http://git.postgresql.org/pg/commitdiff/182200531a92204b0547d337f50b665d222af168

Stephen Frost pushed:

- Dump sequence data based on the TableDataInfo flag.  When considering a
  sequence's Data entry in dumpSequenceData, we were actually looking at the
  sequence definition's dump flag to decide if we should dump the data or not.
  That's generally fine, except for when the sequence data entry was created by
  processExtensionTables() because it's a config sequence.  In that case, the
  sequence itself won't be marked as dumping data because it's part of an
  extension, leading to the need for processExtensionTables() to create the
  sequence data entry.  This leads to extension config sequence data not being
  included in the dump when it should be.  Fix this by looking at the sequence
  data's dump flag instead, just as dumpTableData() was doing for tables (which
  is why config tables were correctly being handled), and add a regression test
  to make sure we don't break it moving forward.  All of this is a bit
  round-about since we can now represent which components of a given dump item
  should be dumped out through the dump flag.  A future improvement might be to
  change checkExtensionMembership() to check for config sequences/tables and set
  the dump flag based on that directly, possibly removing the need for
  processExtensionTables().  Bug found by Daniele Varrazzo.  Discussion:
  https://postgr.es/m/CA+mi_8ZmxQM7+nZ7pJ8uyfxc9V3o=UAG14dVqvftdmvw8OJ3gQ(at)mail(dot)gmail(dot)com
  Patch by Michael Paquier, with some tweaking of the regression tests by me.
  Back-patch to 9.6 where the bug was introduced.
  http://git.postgresql.org/pg/commitdiff/bec96c82f8ff4fcf7ef0f070f6f7447edf106de3


== Pending Patches ==

Michaël Paquier and Karl O. Pinc traded patches to implement
pg_current_logfile().

Michaël Paquier sent in another revision of a patch to rename pg_clog to
pg_xact and pg_subtrans to pg_subxact.

Masahiko Sawada sent in two more revisions of a patch to support FDW
transactions.

Amit Kapila sent in another revision of a patch to parallelize queries
containing subplans.

Haribabu Kommi sent in four more revisions of a patch to implement a
pg_hba_file_settings view.

Beena Emerson and Robert Haas traded patches to enable increasing WAL segment
size.

Amit Kapila and Robert Haas traded patches to enable parallel index scans.

Michaël Paquier sent in a flock of back-patches for an issue in backups on
standbys uncovered by sqlsmith.

Mithun Cy sent in another revision of a patch to cache hash index meta pages.

Nikita Glukhov sent in a patch to implement K-nearest-neighbor for B-Tree
indexes.

Dilip Kumar sent in another revision of a patch to implement parallel bitmap
heap scan.

Magnus Hagander and Michaël Paquier traded patches to implement a version of
jsonb_delete which takes arrays as input.

Haribabu Kommi sent in another revision of a patch to implement a pg_stat_sql
view.

Etsuro Fujita sent in another revision of a patch to fix a bug in foreign joins.

David Rowley sent in two more revisions of a patch to improve performance for
outer joins where the outer side is unique.

Haribabu Kommi sent in another revision of a patch to implement a 64-bit macaddr
type.

Ashutosh Sharma sent in another revision of a patch to add pgstathashindex to
the pgstattuple extension.

Ashutosh Sharma and Jesper Pedersen traded patches to add hash index support to
pageinspect.

Petr Jelínek sent in two more revisions of a patch to enable logical replication
support for the initial data copy.

Petr Jelínek sent in another revision of a patch to add RENAME support for
PUBLICATIONs and SUBSCRIPTIONs.

Petr Jelínek sent in a flock of patches to fix issues in logical replication.

Rafia Sabih sent in another revision of a patch to implement parallel index-only
scans.

Pavan Deolasee sent in another revision of a patch to implement WARM.

Dmitry Fedin sent in a patch to change a misleading comment in pgtime.h.

Yugo Nagata sent in a patch to fix a comment in freelist.c.

Erik Rijkers sent in a patch to improve the logical replication documentation.

Jim Nasby sent in a patch to protect syscache from bloating with negative cache
entries.

Petr Jelínek sent in a patch to fix AFTER trigger execution in logical
replication.

Tom Lane sent in another revision of a patch to prevent the possibility of
UNKNOWN output columns.



pgsql-announce by date

Next:From: Gilles DaroldDate: 2017-01-23 13:48:57
Subject: pgFormatter v1.6 is out
Previous:From: David FetterDate: 2017-01-16 04:45:39
Subject: == PostgreSQL Weekly News - January 15 2017 ==

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