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

== PostgreSQL Weekly News - October 08 2017 ==

From: David Fetter <david(at)fetter(dot)org>
To: PostgreSQL Announce <pgsql-announce(at)postgresql(dot)org>
Subject: == PostgreSQL Weekly News - October 08 2017 ==
Date: 2017-10-08 19:52:42
Message-ID: 20171008195242.GA8413@fetter.org (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-announce
== PostgreSQL Weekly News - October 08 2017 ==

PostgreSQL 10 released!
https://www.postgresql.org/about/news/1786/

== PostgreSQL Product News ==

PL/Proxy 2.8, a database partitioning system implemented as PL language, released.
https://plproxy.github.io

pg_partman v3.1.0, a management system for partitioned tables, released.
https://github.com/keithf4/pg_partman

hypopg 1.1.0, an extension which implements hypothetical indexes, released.
https://github.com/dalibo/hypopg

dbForge Data Compare for PostgreSQL v3.0 released.
https://www.devart.com/dbforge/postgresql/datacompare/whatsnew.html

pgAdmin4 2.0, a web- and native GUI control center for PostgreSQL, released.
https://www.pgadmin.org/

== PostgreSQL Jobs for October ==

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

== PostgreSQL Local ==

PGDay.IT 2017 will take place October 13th, in Milan, Italy.
http://pgday.it

PostgreSQL Conference Europe 2017 will be held on October 24-27, 2017 in the
Warsaw Marriott Hotel, in Warsaw, Poland.
https://2017.pgconf.eu/

pgday.Seoul 2017 will be held in Seoul, South Korea on November 4, 2017.
Korean language information is here:                                                                                                                    
http://pgday.postgresql.kr/

2ndQuadrant PostgreSQL Conference 2017 (2Q PGConf, for short) will be hosted on
November 6th & 7th in New York City, and November 9th in Chicago.
http://www.2qpgconf.com/

PGConf Local: Seattle will be held November 13 - 14, 2017.
https://www.pgconf.us/#Seattle2017

PGDay Australia 2017 will be held on November 17 in Melbourne.
http://2017.pgday.com.au/

PostgreSQL Session will take place November 17th, 2017, in Paris, France.  
http://www.postgresql-sessions.org/en/9/start

PGConf Local: Austin will be held December 4 - 5, 2017. Call for Papers is
now open at https://www.pgconf.us/conferences/Austin2017

PGConf.ASIA 2017 will take place on December 4-6 2017 in Akihabara, Tokyo,
Japan.
http://www.pgconf.asia/EN/2017/

PGConf India 2018 will be on February 22-23, 2018 in Bengaluru, Karnataka.
Proposals are due via https://goo.gl/forms/F9hRjOIsaNasVOAz2 by October 31st, 2017.
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.
The CfP is open through October 31, 2017 at
http://www.socallinuxexpo.org/scale/16x/cfp

== 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 ==

Andres Freund pushed:

- Try to make crash restart test work on windows.  Author: Andres Freund
  Tested-By: Andrew Dunstan Discussion:
  https://postgr.es/m/20170930224424.ud5ilchmclbl5y5n@alap3.anarazel.de
  https://git.postgresql.org/pg/commitdiff/784905795f8aadc09efe2fdae195279d17250f00

- Remove redundant stdint.h include.  Discussion:
  https://postgr.es/m/31674.1506788226@sss.pgh.pa.us
  https://git.postgresql.org/pg/commitdiff/1f2830f9df9f0196ba541c1e253463afe657cb67

- Allow pg_ctl kill to send SIGKILL.  Previously that was disallowed out of an
  abundance of caution. Providing KILL support however is helpful to make the
  013_crash_restart.pl test portable, and there's no actual issue with allowing
  it.  SIGABRT, which has similar consequences except it also dumps core, was
  already allowed.  Author: Andres Freund Discussion:
  https://postgr.es/m/45d42d41-6145-9be1-7261-84acf6d9e344@2ndQuadrant.com
  https://git.postgresql.org/pg/commitdiff/2e83db3ad2da9b073af9ae12916f0b71cf698e1e

- Replace most usages of ntoh[ls] and hton[sl] with pg_bswap.h.  All postgres
  internal usages are replaced, it's just libpq example usages that haven't been
  converted. External users of libpq can't generally rely on including postgres
  internal headers.  Note that this includes replacing open-coded byte swapping
  of 64bit integers (using two 32 bit swaps) with a single 64bit swap.  Where it
  looked applicable, I have removed netinet/in.h and arpa/inet.h usage, which
  previously provided the relevant functionality. It's perfectly possible that I
  missed other reasons for including those, the buildfarm will tell.  Author:
  Andres Freund Discussion:
  https://postgr.es/m/20170927172019.gheidqy6xvlxb325@alap3.anarazel.de
  https://git.postgresql.org/pg/commitdiff/0ba99c84e8c7138143059b281063d4cca5a2bfea

- Correct include file name in inet_aton fallback.  Per buildfarm animal
  frogmouth.  Author: Andres Freund
  https://git.postgresql.org/pg/commitdiff/859759b62f2d2f2f2805e2aa9ebdb167a1b9655c

- Yet another pg_bswap typo in a windows only file.  Per buildfarm animal
  frogmouth.  Brown-Paper-Bagged-By: Andres Freund
  https://git.postgresql.org/pg/commitdiff/0c8b3ee94478ca07c86c09d2399a2ce73c2b922b

- Replace binary search in fmgr_isbuiltin with a lookup array.  Turns out we
  have enough functions that the binary search is quite noticeable in profiles.
  Thus have Gen_fmgrtab.pl build a new mapping from a builtin function's oid to
  an index in the existing fmgr_builtins array. That keeps the additional memory
  usage at a reasonable amount.  Author: Andres Freund, with input from Tom Lane
  Discussion:
  https://postgr.es/m/20170914065128.a5sk7z4xde5uy3ei@alap3.anarazel.de
  https://git.postgresql.org/pg/commitdiff/212e6f34d55c910505f87438d878698223d9a617

- Move genbki.pl's find_defined_symbol to Catalog.pm.  Will be used in
  Gen_fmgrtab.pl in a followup commit.
  https://git.postgresql.org/pg/commitdiff/18f791ab2b6a01a632653d394e046f3daf193ff6

- Attempt to adapt windows build for 212e6f34d55c.  Per buildfarm animal baiji.
  https://git.postgresql.org/pg/commitdiff/15334ad19a776f76cbb725e4e9162a7bce1bd4d0

- Msvc doesn't know UINT16_MAX, replace with PG_UINT16_MAX.  UINT16_MAX usage is
  originating from commit 212e6f34d55c.  Per buildfarm animal currawong.
  https://git.postgresql.org/pg/commitdiff/9eafa2b5b043b84fb9846bd7a57d15ed1ee220c1

Simon Riggs pushed:

- Grammar typo in security warning about md5.
  https://git.postgresql.org/pg/commitdiff/0703c197adb0bf5fa6c99e8af74b13585bdc9056

Peter Eisentraut pushed:

- Expand collation documentation.  Document better how to create custom
  collations and what locale strings ICU accepts.  Explain the ICU examples in
  more detail.  Also update the text on the CREATE COLLATION reference page a
  bit to take ICU more into account.
  https://git.postgresql.org/pg/commitdiff/f41bd4cb90eb1d93631a346bf71d17dfc4beee50

- Document and use SPI_result_code_string().  A lot of semi-internal code just
  prints out numeric SPI error codes, which is not very helpful.  We already
  have an API function to convert the codes to a string, so let's make more use
  of that.  Reviewed-by: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
  https://git.postgresql.org/pg/commitdiff/036166f26e00ab3286ef29a6519525d6291fdfd7

- Move SPI error reporting out of ri_ReportViolation().  These are two
  completely unrelated code paths, so it doesn't make sense to pack them into
  one function.  Add attribute noreturn to ri_ReportViolation().  Reviewed-by:
  Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
  https://git.postgresql.org/pg/commitdiff/582bbcf37fb45ea2e6a851bf9a3c7d7364c7ad32

- Run coverage commands quietly.  They are very chatty by default, but the
  output doesn't seem all that useful for normal operation.  Reviewed-by:
  Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
  https://git.postgresql.org/pg/commitdiff/52e1b1b0425553250db35101f44090898322fb6f

- Remove coverage details view.  This is only useful if we name the different
  tests, which we don't do at the moment.  Reviewed-by: Michael Paquier
  <michael(dot)paquier(at)gmail(dot)com>
  https://git.postgresql.org/pg/commitdiff/c01123630db18561039d4eb17f9502bed0e9d109

- Support coverage on vpath builds.  A few paths needed to be tweaked so
  everything looks into the appropriate directories.  Reviewed-by: Michael
  Paquier <michael(dot)paquier(at)gmail(dot)com>
  https://git.postgresql.org/pg/commitdiff/c3d9a66024a93e6d0380bdd1b18cb03a67216b72

Álvaro Herrera pushed:

- Fix coding rules violations in walreceiver.c.  1. Since commit b1a9bad9e744 we
  had pstrdup() inside a spinlock-protected critical section; reported by
  Andreas Seltenreich.  Turn those into strlcpy() to stack-allocated variables
  instead.  Backpatch to 9.6.  2. Since commit 9ed551e0a4fd we had a pfree()
  uselessly inside a spinlock-protected critical section.  Tom Lane noticed in
  code review.  Move down.  Backpatch to 9.6.  3. Since commit 64233902d22b we
  had GetCurrentTimestamp() (a kernel call) inside a spinlock-protected critical
  section.  Tom Lane noticed in code review.  Move it up.  Backpatch to 9.2.  4.
  Since commit 1bb2558046cc we did elog(PANIC) while holding spinlock.  Tom Lane
  noticed in code review.  Release spinlock before dying.  Backpatch to 9.2.
  Discussion: https://postgr.es/m/87h8vhtgj2.fsf@ansel.ydns.eu
  https://git.postgresql.org/pg/commitdiff/89e434b59caffeeeb7478653c74ad5d7a50d2e96

- Fix traversal of half-frozen update chains.  When some tuple versions in an
  update chain are frozen due to them being older than freeze_min_age, the
  xmax/xmin trail can become broken.  This breaks HOT (and probably other
  things).  A subsequent VACUUM can break things in more serious ways, such as
  leaving orphan heap-only tuples whose root HOT redirect items were removed.
  This can be seen because index creation (or REINDEX) complain like ERROR:
  XX000: failed to find parent tuple for heap-only tuple at (0,7) in table "t"
  Because of relfrozenxid contraints, we cannot avoid the freezing of the early
  tuples, so we must cope with the results: whenever we see an Xmin of
  FrozenTransactionId, consider it a match for whatever the previous Xmax value
  was.  This problem seems to have appeared in 9.3 with multixact changes,
  though strictly speaking it seems unrelated.  Since 9.4 we have commit
  37484ad2a "Change the way we mark tuples as frozen", so the fix is simple:
  just compare the raw Xmin (still stored in the tuple header, since freezing
  merely set an infomask bit) to the Xmax.  But in 9.3 we rewrite the Xmin value
  to FrozenTransactionId, so the original value is lost and we have nothing to
  compare the Xmax with.  To cope with that case we need to compare the Xmin
  with FrozenXid, assume it's a match, and hope for the best.  Sadly, since you
  can pg_upgrade a 9.3 instance containing half-frozen pages to newer releases,
  we need to keep the old check in newer versions too, which seems a bit
  brittle; I hope we can somehow get rid of that.  I didn't optimize the new
  function for performance.  The new coding is probably a bit slower than
  before, since there is a function call rather than a straight comparison, but
  I'd rather have it work correctly than be fast but wrong.  This is a followup
  after 20b655224249 fixed a few related problems.  Apparently, in 9.6 and up
  there are more ways to get into trouble, but in 9.3 - 9.5 I cannot reproduce a
  problem anymore with this patch, so there must be a separate bug.
  Reported-by: Peter Geoghegan Diagnosed-by: Peter Geoghegan, Michael Paquier,
  Daniel Wood, Yi Wen Wong, Álvaro Discussion:
  https://postgr.es/m/CAH2-Wznm4rCrhFAiwKPWTpEw2bXDtgROZK7jWWGucXeH3D1fmA@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/a5736bf754c82d8b86674e199e232096c679201d

Tom Lane pushed:

- Fix race condition with unprotected use of a latch pointer variable.  Commit
  597a87ccc introduced a latch pointer variable to replace use of a long-lived
  shared latch in the shared WalRcvData structure.  This was not well thought
  out, because there are now hazards of the pointer variable changing while it's
  being inspected by another process.  This could obviously lead to a core dump
  in code like if (WalRcv->latch) SetLatch(WalRcv->latch); and there's a more
  remote risk of a torn read, if we have any platforms where reading/writing a
  pointer is not atomic.  An actual problem would occur only if the walreceiver
  process exits (gracefully) while the startup process is trying to signal it,
  but that seems well within the realm of possibility.  To fix, treat the
  pointer variable (not the referenced latch) as being protected by the
  WalRcv->mutex spinlock.  There remains a race condition that we could apply
  SetLatch to a process latch that no longer belongs to the walreceiver, but I
  believe that's harmless: at worst it'd cause an extra wakeup of the next
  process to use that PGPROC structure.  Back-patch to v10 where the faulty code
  was added.  Discussion: https://postgr.es/m/22735.1507048202@sss.pgh.pa.us
  https://git.postgresql.org/pg/commitdiff/45f9d08684d954b0e514b69f270e763d2785dd53

- Allow multiple tables to be specified in one VACUUM or ANALYZE command.  Not
  much to say about this; does what it says on the tin.  However, formerly, if
  there was a column list then the ANALYZE action was implied; now it must be
  specified, or you get an error.  This is because it would otherwise be a bit
  unclear what the user meant if some tables have column lists and some don't.
  Nathan Bossart, reviewed by Michael Paquier and Masahiko Sawada, with some
  editorialization by me Discussion:
  https://postgr.es/m/E061A8E3-5E3D-494D-94F0-E8A9B312BBFC@amazon.com
  https://git.postgresql.org/pg/commitdiff/11d8d72c27a64ea4e30adce11cf6c4f3dd3e60db

- Adjust git_changelog for new-style release tags.  It wasn't on board with
  REL_n_n format.
  https://git.postgresql.org/pg/commitdiff/4736d74479745f0f5a0129fba4628a742034b90e

- Improve comments in vacuum_rel() and analyze_rel().  Remove obsolete
  references to get_rel_oids().  Avoid listing specific relkinds in the
  comments, since we seem unable to keep such things in sync with the code, and
  it's not all that helpful anyhow.  Noted by Michael Paquier, though I rewrote
  the comments a bit more.  Discussion:
  https://postgr.es/m/CAB7nPqTWiN9zwKTaOrsnKiGDChqRt7C1+CiiDk4N4OMn92rs6A@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/4d85c2900b113e331925baf308cc7fc75ac4530b

- Fix typo in README.
  s/BeginInternalSubtransaction/BeginInternalSubTransaction/
  https://git.postgresql.org/pg/commitdiff/fe9ba28ee852bb968bc8948d172c6bc0c70c50df

- #ifdef out some dead code in psql/mainloop.c.  This pg_send_history() call is
  unreachable, since the block it's in is currently only entered in
  !cur_cmd_interactive mode.  But rather than just delete it, make it #ifdef
  NOT_USED, in hopes that we'll remember to enable it if we ever change that
  decision.  Per report from David Binderman.  Since this is basically cosmetic,
  I see no great need to back-patch.  Discussion:
  https://postgr.es/m/HE1PR0802MB233122B61F00A15E035C83BE9C710@HE1PR0802MB2331.eurprd08.prod.outlook.com
  https://git.postgresql.org/pg/commitdiff/3620569fecc6c2edb1cccfbba39b86c4e7d2faae

- Fix access-off-end-of-array in clog.c.  Sloppy loop coding in
  set_status_by_pages() resulted in fetching one array element more than it
  should from the subxids[] array.  The odds of this resulting in SIGSEGV are
  pretty small, but we've certainly seen that happen with similar mistakes
  elsewhere.  While at it, we can get rid of an extra TransactionIdToPage()
  calculation per loop.  Per report from David Binderman.  Back-patch to all
  supported branches, since this code is quite old.  Discussion:
  https://postgr.es/m/HE1PR0802MB2331CBA919CBFFF0C465EB429C710@HE1PR0802MB2331.eurprd08.prod.outlook.com
  https://git.postgresql.org/pg/commitdiff/6b87416c9a4dd305b76e619ecac36e2b968462f8

- Fix intra-query memory leakage in nodeProjectSet.c.  Both
  ExecMakeFunctionResultSet() and evaluation of simple expressions need to be
  done in the per-tuple memory context, not per-query, else we leak data until
  end of query.  This is a consideration that was missed while refactoring code
  in the ProjectSet patch (note that in pre-v10, ExecMakeFunctionResult is
  called in the per-tuple context).  Per bug #14843 from Ben M.  Diagnosed
  independently by Andres and myself.  Discussion:
  https://postgr.es/m/20171005230321.28561.15927@wrigleys.postgresql.org
  https://git.postgresql.org/pg/commitdiff/a1c2c430d33e0945da234b025b78bd265c8bdfb5

- Fix crash when logical decoding is invoked from a PL function.  The logical
  decoding functions do BeginInternalSubTransaction and
  RollbackAndReleaseCurrentSubTransaction to clean up after themselves.  It
  turns out that AtEOSubXact_SPI has an unrecognized assumption that we always
  need to cancel the active SPI operation in the SPI context that surrounds the
  subtransaction (if there is one).  That's true when the
  RollbackAndReleaseCurrentSubTransaction call is coming from the SPI-using
  function itself, but not when it's happening inside some unrelated function
  invoked by a SPI query.  In practice the affected callers are the various PLs.
  To fix, record the current subtransaction ID when we begin a SPI operation,
  and clean up only if that ID is the subtransaction being canceled.  Also,
  remove AtEOSubXact_SPI's assertion that it must have cleaned up the
  surrounding SPI context's active tuptable.  That's proven wrong by the same
  test case.  Also clarify (or, if you prefer, reinterpret) the calling
  conventions for _SPI_begin_call and _SPI_end_call.  The memory context cleanup
  in the latter means that these have always had the flavor of a matched
  resource-management pair, but they weren't documented that way before.  Per
  report from Ben Chobot.  Back-patch to 9.4 where logical decoding came in.  In
  principle, the SPI changes should go all the way back, since the problem dates
  back to commit 7ec1c5a86.  But given the lack of field complaints it seems few
  people are using internal subtransactions in this way.  So I don't feel a need
  to take any risks in 9.2/9.3.  Discussion:
  https://postgr.es/m/73FBA179-C68C-4540-9473-71E865408B15@silentmedia.com
  https://git.postgresql.org/pg/commitdiff/1518d07842dcb412ea6b8bb8172c40da7499b174

- Clean up sloppy maintenance of regression test schedule files.  The
  partition_join test was added to a parallel group that was already at the
  maximum of 20 concurrent tests.  The hash_func test wasn't added to
  serial_schedule at all.  The identity and partition_join tests were added to
  serial_schedule with the aid of a dartboard, rather than maintaining
  consistency with parallel_schedule.  There are proposals afoot to make these
  sorts of errors harder to make, but in the meantime let's fix the ones already
  in place.  Discussion:
  https://postgr.es/m/a37e9c57-22d4-1b82-1270-4501cd2e984e@2ndquadrant.com
  https://git.postgresql.org/pg/commitdiff/1fdab4d5aa47d8a2bb29ccb1122b0158f6db221f

- Enforce our convention about max number of parallel regression tests.  We have
  a very old rule that parallel_schedule should have no more than twenty tests
  in any one parallel group, so as to provide a bound on the number of
  concurrently running processes needed to pass the tests.  But people keep
  forgetting the rule, so let's add a few lines of code to check it.
  Discussion:
  https://postgr.es/m/a37e9c57-22d4-1b82-1270-4501cd2e984e@2ndquadrant.com
  https://git.postgresql.org/pg/commitdiff/ef73a8162a5fe9c4b2f895bf9fb660f1aabc796c

- Improve pg_regress's error reporting for schedule-file problems.  The previous
  coding here trashed the line buffer as it scanned it, making it impossible to
  print the source line in subsequent error messages.  With a few
  save/restore/strdup pushups we can improve that situation.  In passing, move
  the free'ing of the various strings that are collected while processing one
  set of tests down to the bottom of the loop.  That's simpler, less surprising,
  and should make valgrind less unhappy about the strings that were previously
  leaked by the last iteration.
  https://git.postgresql.org/pg/commitdiff/b11f0d36b224a9673863b4e592f40f179dba3016

- Reduce "X = X" to "X IS NOT NULL", if it's easy to do so.  If the operator is
  a strict btree equality operator, and X isn't volatile, then the clause must
  yield true for any non-null value of X, or null if X is null.  At top level of
  a WHERE clause, we can ignore the distinction between false and null results,
  so it's valid to simplify the clause to "X IS NOT NULL".  This is a useful
  improvement mainly because we'll get a far better selectivity estimate in most
  cases.  Because such cases seldom arise in well-written queries, it is
  unappetizing to expend a lot of planner cycles looking for them ... but it
  turns out that there's a place we can shoehorn this in practically for free,
  because equivclass.c already has to detect and reject candidate equivalences
  of the form X = X.  That doesn't catch every place that it would be valid to
  simplify to X IS NOT NULL, but it catches the typical case.  Working harder
  doesn't seem justified.  Patch by me, reviewed by Petr Jelinek Discussion:
  https://postgr.es/m/CAMjNa7cC4X9YR-vAJS-jSYCajhRDvJQnN7m2sLH1wLh-_Z2bsw@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/8ec5429e2f422f4d570d4909507db0d4ca83bbac

- Increase distance between flush requests during bulk file copies.  copy_file()
  reads and writes data 64KB at a time (with default BLCKSZ), and historically
  has issued a pg_flush_data request after each write.  This turns out to
  interact really badly with macOS's new APFS file system: a large file copy
  takes over 100X longer than it ought to on APFS, as reported by Brent Dearth.
  While that's arguably a macOS bug, it's not clear whether Apple will do
  anything about it in the near future, and in any case experimentation suggests
  that issuing flushes a bit less often can be helpful on other platforms too.
  Hence, rearrange the logic in copy_file() so that flush requests are issued
  once per N writes rather than every time through the loop.  I set the
  FLUSH_DISTANCE to 32MB on macOS (any less than that still results in a
  noticeable speed degradation on APFS), but 1MB elsewhere.  In limited testing
  on Linux and FreeBSD, this seems slightly faster than the previous code, and
  certainly no worse.  It helps noticeably on macOS even with the older HFS
  filesystem.  A simpler change would have been to just increase the size of the
  copy buffer without changing the loop logic, but that seems likely to trash
  the processor cache without really helping much.  Back-patch to 9.6 where we
  introduced msync() as an implementation option for pg_flush_data().  The
  problem seems specific to APFS's mmap/msync support, so I don't think we need
  to go further back.  Discussion:
  https://postgr.es/m/CADkxhTNv-j2jw2g8H57deMeAbfRgYBoLmVuXkC=YCFBXRuCOww@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/643c27e36ff38f40d256c2a05b51a14ae2b26077

Robert Haas pushed:

- Fix more user-visible elog() calls.  Michael Paquier discovered that this
  could be triggered via SQL; give a nicer message instead.  Patch by Michael
  Paquier, reviewed by Masahiko Sawada.  Discussion:
  http://postgr.es/m/CAB7nPqQtPg+LKKtzdKN26judHcvPZ0s1gNigzOT4j8CYuuuBYg@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/c097b271e8a14eac5e6189139deca66796b16a59

- Fix typo.  Etsuro Fujita Discussion:
  http://postgr.es/m/1b2e9ac7-b99a-2769-5e42-afdf62bfa7fa@lab.ntt.co.jp
  https://git.postgresql.org/pg/commitdiff/4b2ba1fe0222b7820a2f4cd52b133baeb91c5a93

- Allow DML commands that create tables to use parallel query.  Haribabu Kommi,
  reviewed by Dilip Kumar and Rafia Sabih.  Various cosmetic changes by me to
  explain why this appears to be safe but allowing inserts in parallel mode in
  general wouldn't be.  Also, I removed the REFRESH MATERIALIZED VIEW case from
  Haribabu's patch, since I'm not convinced that case is OK, and hacked on the
  documentation somewhat.  Discussion:
  http://postgr.es/m/CAJrrPGdo5bak6qnPWe8Kpi8g_jfQEs-G4SYmG9y+OFaw2-dPvA@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/e9baa5e9fa147e00a2466ab2c40eb99c8a700824

- Improve error message when skipping scan of default partition.  It seems like
  a good idea to clearly distinguish between skipping the scan of the new
  partition itself and skipping the scan of the default partition.  Amit Langote
  Discussion:
  http://postgr.es/m/1f08b844-0078-aa8d-452e-7af3bf77d05f@lab.ntt.co.jp
  https://git.postgresql.org/pg/commitdiff/c31e9d4bafd80da52408af5f87fe874c9ca0c952

- On attach, consider skipping validation of subpartitions individually.  If the
  table attached as a partition is itself partitioned, individual partitions
  might have constraints strong enough to skip scanning the table even if the
  table actually attached does not.  This is pretty cheap to check, and possibly
  a big win if it works out.  Amit Langote, with test case changes by me.
  Discussion:
  http://postgr.es/m/1f08b844-0078-aa8d-452e-7af3bf77d05f@lab.ntt.co.jp
  https://git.postgresql.org/pg/commitdiff/14f67a8ee282ebc0de78e773fbd597f460ab4a54

- On CREATE TABLE, consider skipping validation of subpartitions.  This is just
  like commit 14f67a8ee282ebc0de78e773fbd597f460ab4a54, but for CREATE PARTITION
  rather than ATTACH PARTITION.  Jeevan Ladhe, with test case changes by me.
  Discussion:
  http://postgr.es/m/CAOgcT0MWwG8WBw8frFMtRYHAgDD=tpt6U7WcsO_L2k0KYpm4Jg@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/6476b26115f3ef25a9cd87880e0ac5ec5f7a05f6

- Basic partition-wise join functionality.  Instead of joining two partitioned
  tables in their entirety we can, if it is an equi-join on the partition keys,
  join the matching partitions individually.  This involves teaching the planner
  about "other join" rels, which are related to regular join rels in the same
  way that other member rels are related to baserels.  This can use
  significantly more CPU time and memory than regular join planning, because
  there may now be a set of "other" rels not only for every base relation but
  also for every join relation.  In most practical cases, this probably
  shouldn't be a problem, because (1) it's probably unusual to join many tables
  each with many partitions using the partition keys for all joins and (2) if
  you do that scenario then you probably have a big enough machine to handle the
  increased memory cost of planning and (3) the resulting plan is highly likely
  to be better, so what you spend in planning you'll make up on the execution
  side.  All the same, for now, turn this feature off by default.  Currently, we
  can only perform joins between two tables whose partitioning schemes are
  absolutely identical.  It would be nice to cope with other scenarios, such as
  extra partitions on one side or the other with no match on the other side, but
  that will have to wait for a future patch.  Ashutosh Bapat, reviewed and
  tested by Rajkumar Raghuwanshi, Amit Langote, Rafia Sabih, Thomas Munro, Dilip
  Kumar, Antonin Houska, Amit Khandekar, and by me.  A few final adjustments by
  me.  Discussion:
  http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
  Discussion:
  http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/f49842d1ee31b976c681322f76025d7732e860f3

- Copy information from the relcache instead of pointing to it.  We have the
  relations continuously locked, but not open, so relcache pointers are not
  guaranteed to be stable.  Per buildfarm member prion.  Ashutosh Bapat.  I
  fixed a typo.  Discussion:
  http://postgr.es/m/CAFjFpRcRBqoKLZSNmRsjKr81uEP=ennvqSQaXVCCBTXvJ2rW+Q@mail.gmail.com
  https://git.postgresql.org/pg/commitdiff/45866c75507f0757de0da6e90c694a0dbe67d727

== Pending Patches ==

Tom Lane sent in another revision of a patch to improve eval const expressions.

Michaël Paquier sent in another revision of a patch to change detection of
corrupted 2PC files to produce a FATAL error and minimize the window between
history file and end-of-recovery record.

Claudio Freire sent in another revision of a patch to enable VACUUM to use over
1GB of work_mem.

Emre Hasegeli sent in another revision of a patch to improve geometric types.

Robert Haas sent in four revisions of a patch to widen queryId to 64 bits.

Vik Fearing sent in a patch to log idle checkpoints.

Andres Freund sent in a patch to combine expr{Type,Typmod,Collation}() into one
function.

Andres Freund sent in a patch to add pg_strnlen(), a portable implementation of
strlen and fix pnstrdup() to not memcpy() the maximum allowed.

Ildar Musin sent in another revision of a patch to factor out some repetitive
code in RI triggers.

Yura Sokolov sent in two revisions of a patch to make CheckDeadlock do two
passes in order to prevent a deadlock condition it could itself cause under high
load.

Andres Freund sent in another revision of a patch to add configure
infrastructure to detect support for C99's restrict, allow to avoid NUL-byte
management for stringinfos and use in format.c, add more efficient functions to
the pqformat API, use one stringbuffer for all rows printed in printtup.c,
improve the performance of SendRowDescriptionMessage, and replace remaining
printtup uses of pq_sendint with pq_sendintXX.

Alexander Korotkov sent in a patch to add TOAST to all system catalog tables
with ACL.

Nico Williams sent in three revisions of a patch to add an ALWAYS DEFERRED
option for constraints.

Amit Kapila sent in two more revisions of a patch to parallelize queries
containing subplans.

Petr Jelínek sent in a patch to fix an issue in logical replication by setting
assigning GetCurrentCommandId in logical replication's estate.

Alexander Kuzmenkov sent in another revision of a patch to enable a full merge
join on comparison clause.

Amit Khandekar sent in another revision of a patch to enable UPDATEs on
partition keys in declaratively partitioned tables that would have the effect of
moving tuples from one partition to another.

Nathan Bossart sent in a patch to add additional logging for VACUUM and ANALYZE.

Sean Chittenden sent in two more revisions of a patch to fix a bug where the
system failed to use optimized shared memory on Solaris.

Andres Freund sent in another revision of a patch to implement JIT compiling.

Badrul Chowdhury sent in two revisions of a patch to implement wire protocol
negotiation.

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

Masahiko Sawada sent in another revision of a patch to implement block-level
parallel VACUUM.

Thomas Munro sent in another revision of a patch to remove BufFile's isTemp flag
and add BufFileSet for sharing temporary files between backends.

Robert Haas sent in another revision of a patch to change walwriter wakeup.

Shubham Barai sent in another revision of a patch to add predicate locking for
GiST indexes.

Fabrízio de Royes Mello sent in another revision of a patch to add hooks for
session start and end.

Amit Langote sent in a patch to improve error message for
check_default_allows_bound.

Peter Geoghegan sent in another revision of a patch to add a Bloom filter data
structure implementation and use same to add amcheck verification of indexes
against heap.

Craig Ringer sent in a patch to expose the generate_qualified_relation_name
functionality to C by adding get_qualified_relation_name().

Jing Wang sent in another revision of a patch to support to COMMENT ON DATABASE
CURRENT_DATABASE.

Dilip Kumar sent in two more revisions of a patch to improve bitmap costing for
lossy pages.

Tom Lane sent in a patch to enforce max test parallelism.



pgsql-announce by date

Next:From: Gerdan Rezende dos SantosDate: 2017-10-08 20:22:25
Subject: PGDAY Brasilia 2017 - Brazil - 02 December 2017
Previous:From: Marko KreenDate: 2017-10-08 09:31:59
Subject: PL/Proxy 2.8

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