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

== PostgreSQL Weekly News - December 25 2016 ==

From: David Fetter <david(at)fetter(dot)org>
To: PostgreSQL Announce <pgsql-announce(at)postgresql(dot)org>
Subject: == PostgreSQL Weekly News - December 25 2016 ==
Date: 2016-12-25 22:52:58
Message-ID: 20161225225258.GA21777@fetter.org (view raw or whole thread)
Thread:
Lists: pgsql-announce
== PostgreSQL Weekly News - December 25 2016 ==

pgDay Paris 2017 will be held in Paris, France on March 23, 2017.
The CfP is open until January 9, 2017.
http://2017.pgday.paris/callforpapers/

Nordic PGDay 2017 will be held in Stockholm, Sweden, at the Sheraton
Hotel, on March 21, 2017.  The CfP is open until January 9, 2017.
https://2017.nordicpgday.org/cfp/

== PostgreSQL Product News ==

PostgreSQL Automatic Failover (PAF) v2.1.0 released.
https://github.com/dalibo/PAF/releases/tag/v2.1.0

Postgres.app 2.0, a PostgreSQL bundle for OS X, released.
https://github.com/PostgresApp/PostgresApp/releases/v2.0.1/

== PostgreSQL Jobs for December ==

http://archives.postgresql.org/pgsql-jobs/2016-12/threads.php

== PostgreSQL Local ==

PGConf India 2017 will be on March 2-3, 2017 in Bengaluru, Karnataka.
Proposals are due via <papers AT pgconf DOT in> by 31st December, 2016.
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.
The CfP closes January 16, 2017.
http://tinyurl.com/pgDay-Asia-2017-Cfp

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

Magnus Hagander pushed:

- Fix base backup rate limiting in presence of slow i/o When source i/o on disk
  was too slow compared to the rate limiting specified, the system could end up
  with a negative value for sleep that it never got out of, which caused rate
  limiting to effectively be turned off.  Discussion:
  https://postgr.es/m/CABUevEy_-e0YvL4ayoX8bH_Ja9w%2BBHoP6jUgdxZuG2nEj3uAfQ%40mail.gmail.com
  Analysis by me, patch by Antonin Houska
  http://git.postgresql.org/pg/commitdiff/10238fad0389175f71739bc9b4d00bb24d9b8c44

Fujii Masao pushed:

- Support quorum-based synchronous replication.  This feature is also known as
  "quorum commit" especially in discussion on pgsql-hackers.  This commit adds
  the following new syntaxes into synchronous_standby_names GUC. By using FIRST
  and ANY keywords, users can specify the method to choose synchronous standbys
  from the listed servers.  FIRST num_sync (standby_name [, ...]) ANY num_sync
  (standby_name [, ...]) The keyword FIRST specifies a priority-based
  synchronous replication which was available also in 9.6 or before. This method
  makes transaction commits wait until their WAL records are replicated to
  num_sync synchronous standbys chosen based on their priorities.  The keyword
  ANY specifies a quorum-based synchronous replication and makes transaction
  commits wait until their WAL records are replicated to *at least* num_sync
  listed standbys. In this method, the values of sync_state.pg_stat_replication
  for the listed standbys are reported as "quorum". The priority is still
  assigned to each standby, but not used in this method.  The existing syntaxes
  having neither FIRST nor ANY keyword are still supported. They are the same as
  new syntax with FIRST keyword, i.e., a priorirty-based synchronous
  replication.  Author: Masahiko Sawada Reviewed-By: Michael Paquier, Amit
  Kapila and me Discussion:
  <CAD21AoAACi9NeC_ecm+Vahm+MMA6nYh=Kqs3KB3np+MBOS_gZg(at)mail(dot)gmail(dot)com> Many
  thanks to the various individuals who were involved in discussing and
  developing this feature.
  http://git.postgresql.org/pg/commitdiff/3901fd70cc7ccacef1b0549a6835bb7d8dcaae43

- Forbid invalid combination of options in pg_basebackup.  Commit
  56c7d8d4552180fd66fe48423bb2a9bb767c2d87 allowed pg_basebackup to stream WAL
  in tar mode. But there is the restriction that WAL streaming in tar mode works
  only when the value - (dash) is not specified as output directory. This means
  that the combination of three options "-D -", "-F t" and "-X stream" is
  invalid. However, previously, even when those options were specified at the
  same time, pg_basebackup background process unexpectedly started streaming
  WAL.  And then it exited with an error.  This commit changes pg_basebackup so
  that it errors out on such invalid combination of options at the beginning.
  Reviewed by Magnus Hagander, and patch by me.
  http://git.postgresql.org/pg/commitdiff/ecbdc4c555f43b1ac284c734752b00c2ea6f277b

Robert Haas pushed:

- Remove unused file.  This was added in
  105409746499657acdffc109db9d343b464bda1f, but has never been used for anything
  as far as I can tell.  There seems to be no reason to keep it.
  http://git.postgresql.org/pg/commitdiff/668dbbec27da05b35a6972e9d833115dce0b6ccc

- Fix locking problem in _hash_squeezebucket() / _hash_freeovflpage().  A bucket
  squeeze operation needs to lock each page of the bucket before releasing the
  prior page, but the previous coding fumbled the locking when freeing an
  overflow page during a bucket squeeze operation.  Commit
  6d46f4783efe457f74816a75173eb23ed8930020 introduced this bug.  Amit Kapila,
  with help from Kuntal Ghosh and Dilip Kumar, after an initial trouble report
  by Jeff Janes.  Reviewed by me.  I also fixed a problem with a comment.
  http://git.postgresql.org/pg/commitdiff/dd728826c538f000220af98de025c00114ad0631

- Provide a DSA area for all parallel queries.  This will allow future parallel
  query code to dynamically allocate storage shared by all participants.  Thomas
  Munro, with assorted changes by me.
  http://git.postgresql.org/pg/commitdiff/e13029a5ce353574516c64fd1ec9c50201e705fd

- Invalid parent's relcache after CREATE TABLE .. PARTITION OF.  Otherwise,
  subsequent commands in the same transaction see the wrong partition
  descriptor.  Amit Langote.  Reported by Tomas Vondra and David Fetter.
  Reviewed by me.  Discussion:
  http://postgr.es/m/22dd313b-d7fd-22b5-0787-654845c8f849%402ndquadrant.com
  Discussion: http://postgr.es/m/20161215090916.GB20659%40fetter.org
  http://git.postgresql.org/pg/commitdiff/7cd0fd655d681e0ed5f7269fa421d977f1df0889

- Refactor merge path generation code.  This shouldn't change the set of paths
  that get generated in any way, but it is preparatory work for further changes
  to allow a partial path to be merge-joined witih a non-partial path to produce
  a partial join path.  Dilip Kumar, with cosmetic adjustments by me.
  http://git.postgresql.org/pg/commitdiff/59649c3f1cbd536314c0060dcabd234deab148b2

- Fix corner-case bug in WaitEventSetWaitBlock on Windows.  If we do not reset
  the FD_READ event, WaitForMultipleObjects won't return it again again unless
  we've meanwhile read from the socket, which is generally true but not
  guaranteed.  WaitEventSetWaitBlock itself may fail to return the event to the
  caller if the latch is also set, and even if we changed that, the caller isn't
  obliged to handle all returned events at once.  On non-Windows systems, the
  socket-read event is purely level-triggered, so this issue does not exist.  To
  fix, make Windows reset the event when needed.  This bug was introduced by
  98a64d0bd713cb89e61bef6432befc4b7b5da59e, and causes hangs when trying to use
  the pldebugger extension.  Patch by Amit Kapial.  Reported and tested by
  Ashutosh Sharma, who also provided some analysis.  Further analysis by Michael
  Paquier.
  http://git.postgresql.org/pg/commitdiff/3b790d256f8489d0765c3389d6860f1c6b4a9b2d

- Refactor partition tuple routing code to reduce duplication.  Amit Langote
  http://git.postgresql.org/pg/commitdiff/1fc5c4945047e8e8c7aa1644b52dd0187b729181

- Convert elog() to ereport() and do some wordsmithing.  It's not entirely clear
  that we should log a message here at all, but it's certainly wrong to use
  elog() for a message that should clearly be translatable.  Amit Langote
  http://git.postgresql.org/pg/commitdiff/cd510f04137a1436ad6029da4998f5224395a08d

- Code review for ATExecAttachPartition.  Amit Langote.  Most of this reported
  by Álvaro Herrera.
  http://git.postgresql.org/pg/commitdiff/3ee80672847c4100d5f9efdb9ea19cb96506d089

- Fix broken error check in _hash_doinsert.  You can't just cast a HashMetaPage
  to a Page, because the meta page data is stored after the page header, not at
  offset 0.  Fortunately, this didn't break anything because it happens to find
  hashm_bsize at the offset at which it expects to find pd_pagesize_version, and
  the values are close enough to the same that this works out.  Still, it's a
  bug, so back-patch to all supported versions.  Mithun Cy, revised a bit by me.
  http://git.postgresql.org/pg/commitdiff/097e41439d69e11fb870e009b1ac64dda4f01c3d

- Fix tuple routing in cases where tuple descriptors don't match.  The previous
  coding failed to work correctly when we have a multi-level partitioned
  hierarchy where tables at successive levels have different attribute numbers
  for the partition key attributes.  To fix, have each PartitionDispatch object
  store a standalone TupleTableSlot initialized with the TupleDesc of the
  corresponding partitioned table, along with a TupleConversionMap to map tuples
  from the its parent's rowtype to own rowtype.  After tuple routing chooses a
  leaf partition, we must use the leaf partition's tuple descriptor, not the
  root table's.  To that end, a dedicated TupleTableSlot for tuple routing is
  now allocated in EState.  Amit Langote
  http://git.postgresql.org/pg/commitdiff/2ac3ef7a01df859c62d0a02333b646d65eaec5ff

- Remove _hash_chgbufaccess().  This is basically for the same reasons I got rid
  of _hash_wrtbuf() in commit 25216c98938495fd741bf585dcbef45b3a9ffd40: it's not
  convenient to have a function which encapsulates MarkBufferDirty(), especially
  as we move towards having hash indexes be WAL-logged.  Patch by me, reviewed
  (but not entirely endorsed) by Amit Kapila.
  http://git.postgresql.org/pg/commitdiff/7819ba1ef6c5297b7e27878d2b3d30c5bcef8939

- Remove sql_inheritance GUC.  This backward-compatibility GUC is long overdue
  for removal.  Discussion:
  http://postgr.es/m/CA+TgmoYe+EG7LdYX6pkcNxr4ygkP4+A=jm9o-CPXyOvRiCNwaQ(at)mail(dot)gmail(dot)com
  http://git.postgresql.org/pg/commitdiff/e13486eba05cc46951a34263d19b65d1eca0176b

Tom Lane pushed:

- Fix handling of phrase operator removal while removing tsquery stopwords.  The
  distance of a removed phrase operator should propagate up to a parent phrase
  operator if there is one, but this only worked correctly in left-deep trees.
  Throwing in a few parentheses confused it completely, as indeed was
  illustrated by bizarre results in existing regression test cases.  To fix,
  track unaccounted-for distances that should propagate to the left and to the
  right of the current node, rather than trying to make it work with only one
  returned distance.  Also make some adjustments to behave as well as we can for
  cases of intermixed phrase and regular (AND/OR) operators.  I don't think it's
  possible to be 100% correct for that without a rethinking of the tsquery
  representation; for example, maybe we should just not drop stopword nodes at
  all underneath phrase operators.  But this is better than it was, and changing
  tsquery representation wouldn't be safely back-patchable.  While at it, I
  simplified the API of the clean_fakeval_intree function a bit by getting rid
  of the "char *result" output parameter; that wasn't doing anything that wasn't
  redundant with whether the result node is NULL or not, and testing for NULL
  seems a lot clearer/safer.  This is part of a larger project to fix various
  infelicities in the phrase-search implementation, but this part seems
  comittable on its own.  Back-patch to 9.6 where phrase operators were
  introduced.  Discussion: https://postgr.es/m/28215(dot)1481999808(at)sss(dot)pgh(dot)pa(dot)us
  Discussion: https://postgr.es/m/26706(dot)1482087250(at)sss(dot)pgh(dot)pa(dot)us
  http://git.postgresql.org/pg/commitdiff/2604438472c897fbbd1568b1a8ee177ba8cdb6e3

- Fix minor error message style violation.  Primary error messages should not
  end with a period, since they're generally not written as full sentences.
  Oversight in 41493bac3.
  http://git.postgresql.org/pg/commitdiff/7d41a2bd3eef4de64ae8f6f683457f12f9407c5d

- Fix minor oversights in nodeAgg.c.  aggstate->evalproj is always set up by
  ExecInitAgg, so there's no need to test.  Doing so led Coverity to think that
  we might be intending "slot" to be possibly NULL here, and it quite properly
  complained that the rest of combine_aggregates() wasn't prepared for that.
  Also fix a couple of obvious thinkos in Asserts checking that "inputoff" isn't
  past the end of the slot.  Errors introduced in commit 8ed3f11bb, so no need
  for back-patch.
  http://git.postgresql.org/pg/commitdiff/c080b223a7a3991524a5287416a0ad756c15a098

- Fix strange behavior (and possible crashes) in full text phrase search.  In an
  attempt to simplify the tsquery matching engine, the original phrase search
  patch invented rewrite rules that would rearrange a tsquery so that no
  AND/OR/NOT operator appeared below a PHRASE operator.  But this approach had
  numerous problems.  The rearrangement step was missed by ts_rewrite (and
  perhaps other places), allowing tsqueries to be created that would cause
  Assert failures or perhaps crashes at execution, as reported by Andreas
  Seltenreich.  The rewrite rules effectively defined semantics for operators
  underneath PHRASE that were buggy, or at least unintuitive.  And because
  rewriting was done in tsqueryin() rather than at execution, the rearrangement
  was user-visible, which is not very desirable --- for example, it might cause
  unexpected matches or failures to match in ts_rewrite.  As a somewhat
  independent problem, the behavior of nested PHRASE operators was only sane for
  left-deep trees; queries like "x <-> (y <-> z)" did not behave intuitively at
  all.  To fix, get rid of the rewrite logic altogether, and instead teach the
  tsquery execution engine to manage AND/OR/NOT below a PHRASE operator by
  explicitly computing the match location(s) and match widths for these
  operators.  This requires introducing some additional fields into the publicly
  visible ExecPhraseData struct; but since there's no way for third-party code
  to pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
  as long as we don't move the offsets of the existing fields.  Another related
  problem was that index searches supposed that "!x <-> y" could be lossily
  approximated as "!x & y", which isn't correct because the latter will reject,
  say, "x q y" which the query itself accepts.  This required some tweaking in
  TS_execute_ternary along with the main tsquery engine.  Back-patch to 9.6
  where phrase operators were introduced.  While this could be argued to change
  behavior more than we'd like in a stable branch, we have to do something about
  the crash hazards and index-vs-seqscan inconsistency, and it doesn't seem
  desirable to let the unintuitive behaviors induced by the rewriting
  implementation stand as precedent.  Discussion:
  https://postgr.es/m/28215(dot)1481999808(at)sss(dot)pgh(dot)pa(dot)us Discussion:
  https://postgr.es/m/26706(dot)1482087250(at)sss(dot)pgh(dot)pa(dot)us
  http://git.postgresql.org/pg/commitdiff/89fcea1ace40bc025beea2758a80bcd56a319a6f

- Fix detection of unfinished Unicode surrogate pair at end of string.  The
  U&'...' and U&"..." syntaxes silently discarded a surrogate pair start (that
  is, a code between U+D800 and U+DBFF) if it occurred at the very end of the
  string.  This seems like an obvious oversight, since we throw an error for
  every other invalid combination of surrogate characters, including the very
  same situation in E'...' syntax.  This has been wrong since the pair
  processing was added (in 9.0), so back-patch to all supported branches.
  Discussion: https://postgr.es/m/19113(dot)1482337898(at)sss(dot)pgh(dot)pa(dot)us
  http://git.postgresql.org/pg/commitdiff/a8ae12322ae056ebbe9d83cf16b4c92e86a6ac28

- Give a useful error message if uuid-ossp is built without preconfiguration.
  Before commit b8cc8f947, it was possible to build contrib/uuid-ossp without
  having told configure you meant to; you could just cd into that directory and
  "make".  That no longer works because the code depends on configure to have
  done header and library probes, but the ensuing error messages are not so easy
  to interpret if you're not an old C hand.  We've gotten a couple of complaints
  recently from people trying to do this the low-tech way, so add an explicit
  #error directing the user to use --with-uuid.  (In principle we might want to
  do something similar in the other optionally-built contrib modules; but I
  don't think any of the others have ever worked without preconfiguration, so
  there are no bad habits to break people of.) Back-patch to 9.4 where the
  previous commit came in.  Report:
  https://postgr.es/m/CAHeEsBf42AWTnk=1qJvFv+mYgRFm07Knsfuc86Ono8nRjf3tvQ(at)mail(dot)gmail(dot)com
  Report:
  https://postgr.es/m/CAKYdkBrUaZX+F6KpmzoHqMtiUqCtAW_w6Dgvr6F0WTiopuGxow(at)mail(dot)gmail(dot)com
  http://git.postgresql.org/pg/commitdiff/b86515da1a73d0a2e23aca728f18b5f9e809e89f

- Fix handling of expanded objects in CoerceToDomain and CASE execution.  When
  the input value to a CoerceToDomain expression node is a read-write expanded
  datum, we should pass a read-only pointer to any domain CHECK expressions and
  then return the original read-write pointer as the expression result.
  Previously we were blindly passing the same pointer to all the consumers of
  the value, making it possible for a function in CHECK to modify or even delete
  the expanded value.  (Since a plpgsql function will absorb a passed-in
  read-write expanded array as a local variable value, it will in fact delete
  the value on exit.) A similar hazard of passing the same read-write pointer to
  multiple consumers exists in domain_check() and in ExecEvalCase, so fix those
  too.  The fix requires adding MakeExpandedObjectReadOnly calls at the
  appropriate places, which is simple enough except that we need to get the data
  type's typlen from somewhere.  For the domain cases, solve this by redefining
  DomainConstraintRef.tcache as okay for callers to access; there wasn't any
  reason for the original convention against that, other than not wanting the
  API of typcache.c to be any wider than it had to be.  For CASE, there's no
  good solution except to add a syscache lookup during executor start.  Per bug
  #14472 from Marcos Castedo.  Back-patch to 9.5 where expanded values were
  introduced.  Discussion: https://postgr.es/m/15225(dot)1482431619(at)sss(dot)pgh(dot)pa(dot)us
  http://git.postgresql.org/pg/commitdiff/cd1b215692d2cadf499936dba05f1f60bce59344

- Fix CREATE TABLE ... LIKE ... WITH OIDS.  Having a WITH OIDS specification
  should result in the creation of an OID column, but commit b943f502b broke
  that in the case that there were LIKE tables without OIDS.  Commentary in that
  patch makes it look like this was intentional, but if so it was based on a
  faulty reading of what inheritance does: the parent tables can add an OID
  column, but they can't subtract one.  AFAICS, the behavior ought to be that
  you get an OID column if any of the inherited tables, LIKE tables, or WITH
  clause ask for one.  Also, revert that patch's unnecessary split of
  transformCreateStmt's loop over the tableElts list into two passes.  That
  seems to have been based on a misunderstanding as well: we already have
  two-pass processing here, we don't need three passes.  Per bug #14474 from
  Jeff Dafoe.  Back-patch to 9.6 where the misbehavior was introduced.  Report:
  https://postgr.es/m/20161222145304(dot)25620(dot)47445(at)wrigleys(dot)postgresql(dot)org
  http://git.postgresql.org/pg/commitdiff/1ead0208b2178089b024caa2d1465a3f3056a45c

- Spellcheck: s/descendent/descendant/g.  I got a little annoyed by reading
  documentation paragraphs containing both spellings within a few lines of each
  other.  My dictionary says "descendant" is the preferred spelling, and it's
  certainly the majority usage in our tree, so standardize on that.  For one
  usage in parallel.sgml, I thought it better to rewrite to avoid the term
  altogether.
  http://git.postgresql.org/pg/commitdiff/ff33d1456ea098e160cbbc74b332656c06abc2ab

- Doc: improve index entry for "median".  We had an index entry for "median"
  attached to the percentile_cont function entry, which was pretty useless
  because a person following the link would never realize that that function was
  the one they were being hinted to use.  Instead, make the index entry point at
  the example in syntax-aggregates, and add a <seealso> link to "percentile".
  Also, since that example explicitly claims to be calculating the median, make
  it use percentile_cont not percentile_disc.  This makes no difference in terms
  of the larger goals of that section, but so far as I can find, nearly everyone
  thinks that "median" means the continuous not discrete calculation.  Per gripe
  from Steven Winfield.  Back-patch to 9.4 where we introduced percentile_cont.
  Discussion:
  https://postgr.es/m/20161223102056(dot)25614(dot)1166(at)wrigleys(dot)postgresql(dot)org
  http://git.postgresql.org/pg/commitdiff/3c9d398484fb6e188e665be8299d6e5e89924c94

- Replace enum InhOption with simple boolean.  Now that it has only INH_NO and
  INH_YES values, it's just weird that it's not a plain bool, so make it that
  way.  Also rename RangeVar.inhOpt to "inh", to be like RangeTblEntry.inh.  My
  recollection is that we gave it a different name specifically because it had a
  different representation than the derived bool value, but it no longer does.
  And this is a good forcing function to be sure we catch any places that are
  affected by the change.  Bump catversion because of possible effect on stored
  RangeVar nodes.  I'm not exactly convinced that we ever store RangeVar on
  disk, but we have a readfuncs function for it, so be cautious.  (If we do do
  so, then commit e13486eba was in error not to bump catversion.) Follow-on to
  commit e13486eba.  Discussion:
  http://postgr.es/m/CA+TgmoYe+EG7LdYX6pkcNxr4ygkP4+A=jm9o-CPXyOvRiCNwaQ(at)mail(dot)gmail(dot)com
  http://git.postgresql.org/pg/commitdiff/fe591f8bf68db9bf81f278acce6239ee68cd4ed6

- Fix incorrect error reporting for duplicate data in \crosstabview.
  \crosstabview's complaint about multiple entries for the same crosstab cell
  quoted the wrong row and/or column values.  It would accidentally appear to
  work if the data had been in strcmp() order to start with, which probably
  explains how we missed noticing this during development.  This could be fixed
  in more than one way, but the way I chose was to hang onto both result
  pointers from bsearch() and use those to get at the value names.  In passing,
  avoid casting away const in the bsearch comparison functions.  No bug there,
  just poor style.  Per bug #14476 from Tomonari Katsumata.  Back-patch to 9.6
  where \crosstabview was introduced.  Report:
  https://postgr.es/m/20161225021519(dot)10139(dot)45460(at)wrigleys(dot)postgresql(dot)org
  http://git.postgresql.org/pg/commitdiff/a3aef88e6a9c5822eb4a5ad0744b15dc6e8a5d86

Heikki Linnakangas pushed:

- Fix sharing Agg transition state of DISTINCT or ordered aggs.  If a query
  contained two aggregates that could share the transition value, we would
  correctly collect the input into a tuplesort only once, but incorrectly run
  the transition function over the accumulated input twice, in
  finalize_aggregates(). That caused a crash, when we tried to call
  tuplesort_performsort() on an already-freed NULL tuplestore.  Backport to 9.6,
  where sharing of transition state and this bug were introduced.  Analysis by
  Tom Lane.  Discussion:
  https://www.postgresql.org/message-id/ac5b0b69-744c-9114-6218-8300ac920e61@iki.fi
  http://git.postgresql.org/pg/commitdiff/db80acfc9d50ac56811d22802ab3d822ab313055

- Simplify tape block format.  No more indirect blocks. The blocks form a linked
  list instead.  This saves some memory, because we don't need to have a buffer
  in memory to hold the indirect block (or blocks). To reflect that,
  TAPE_BUFFER_OVERHEAD is reduced from 3 to 1 buffer, which allows using more
  memory for building the initial runs.  Reviewed by Peter Geoghegan and Robert
  Haas.  Discussion:
  https://www.postgresql.org/message-id/34678beb-938e-646e-db9f-a7def5c44ada%40iki.fi
  http://git.postgresql.org/pg/commitdiff/01ec25631fe0eae6af67c29c61a358dc6b92ed3c

Peter Eisentraut pushed:

- Add pg_sequence system catalog.  Move sequence metadata (start, increment,
  etc.) into a proper system catalog instead of storing it in the sequence heap
  object.  This separates the metadata from the sequence data.  Sequence
  metadata is now operated on transactionally by DDL commands, whereas
  previously rollbacks of sequence-related DDL commands would be ignored.
  Reviewed-by: Andreas Karlsson <andreas(at)proxel(dot)se>
  http://git.postgresql.org/pg/commitdiff/1753b1b027035029c2a2a1649065762fafbf63f3

- Reorder pg_sequence columns to avoid alignment issue.  On AIX, doubles are
  aligned at 4 bytes, but int64 is aligned at 8 bytes.  Our code assumes that
  doubles have alignment that can also be applied to int64, but that fails in
  this case.  One effect is that heap_form_tuple() writes tuples in a different
  layout than Form_pg_sequence expects.  Rather than rewrite the whole alignment
  code, work around the issue by reordering the columns in pg_sequence so that
  the first int64 column naturally comes out at an 8-byte boundary.
  http://git.postgresql.org/pg/commitdiff/f3b421da5f4addc95812b9db05a24972b8fd9739

- doc: Further speed improvements for HTML XSLT build
  http://git.postgresql.org/pg/commitdiff/909cb78a8cce73c9678ddb3269b56e31b56e084b

- Update sequence_1.out for recent changes
  http://git.postgresql.org/pg/commitdiff/22434dd06bbc5774c7bbffa5bf2bef3ead50c2f2

- pg_dump: Remove obsolete handling of sequence names.  There was code that
  attempted to check whether the sequence name stored inside the sequence was
  the same as the name in pg_class.  But that code was already ifdef'ed out, and
  now that the sequence no longer stores its own name, it's altogether obsolete,
  so remove it.
  http://git.postgresql.org/pg/commitdiff/3e6639a465a5702d0aa98fc756b5ab8c7f97cde8

- Remove unnecessary casts of makeNode() result.  makeNode() is already a macro
  that has the right result pointer type, so casting it again to the same type
  is unnecessary.
  http://git.postgresql.org/pg/commitdiff/158df30359025d74daee74a3b927fd07c3b1a413

Dean Rasheed pushed:

- Fix order of operations in CREATE OR REPLACE VIEW.  When CREATE OR REPLACE
  VIEW acts on an existing view, don't update the view options until after the
  view query has been updated.  This is necessary in the case where CREATE OR
  REPLACE VIEW is used on an existing view that is not updatable, and the new
  view is updatable and specifies the WITH CHECK OPTION. In this case,
  attempting to apply the new options to the view before updating its query
  fails, because the options are applied using the ALTER TABLE infrastructure
  which checks that WITH CHECK OPTION is only applied to an updatable view.  If
  new columns are being added to the view, that is also done using the ALTER
  TABLE infrastructure, but it is important that that still be done before
  updating the view query, because the rules system checks that the query
  columns match those on the view relation. Added a comment to explain that, in
  case someone is tempted to move that to where the view options are now being
  set.  Back-patch to 9.4 where WITH CHECK OPTION was added.  Report:
  https://postgr.es/m/CAEZATCUp%3Dz%3Ds4SzZjr14bfct_bdJNwMPi-gFi3Xc5k1ntbsAgQ%40mail.gmail.com
  http://git.postgresql.org/pg/commitdiff/58b1362642d47bd7a7ed1157035a38671555e860

Stephen Frost pushed:

- Fix dumping of casts and transforms using built-in functions. In pg_dump.c
  dumpCast() and dumpTransform(), we would happily ignore the cast or transform
  if it happened to use a built-in function because we weren't including the
  information about built-in functions when querying pg_proc from getFuncs().
  Modify the query in getFuncs() to also gather information about functions
  which are used by user-defined casts and transforms (where "user-defined"
  means "has an OID >= FirstNormalObjectId").  This also adds to the TAP
  regression tests for 9.6 and master to cover these types of objects.
  Back-patch all the way for casts, back to 9.5 for transforms.  Discussion:
  https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net
  http://git.postgresql.org/pg/commitdiff/2259bf672cb45b4104dcb835354beeb1c6105b0e

- For 8.0 servers, get last built-in oid from pg_database.  We didn't start
  ensuring that all built-in objects had OIDs less than 16384 until 8.1, so for
  8.0 servers we still need to query the value out of pg_database.  We need
  this, in particular, to distinguish which casts were built-in and which were
  user-defined.  For HEAD, we only worry about going back to 8.0, for the
  back-branches, we also ensure that 7.0-7.4 work.  Discussion:
  https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net
  http://git.postgresql.org/pg/commitdiff/19990918d3fa2a445561627ed415b5891602f7fe

- Improve ALTER TABLE documentation.  The ALTER TABLE documentation wasn't
  terribly clear when it came to which commands could be combined together and
  what it meant when they were.  In particular, SET TABLESPACE *can* be combined
  with other commands, when it's operating against a single table, but not when
  multiple tables are being moved with ALL IN TABLESPACE.  Further, the actions
  are applied together but not really in 'parallel', at least today.  Pointed
  out by: Amit Langote.  Improved wording from Tom.  Back-patch to 9.4, where
  the ALL IN TABLESPACE option was added.  Discussion:
  https://www.postgresql.org/message-id/14c535b4-13ef-0590-1b98-76af355a0763%40lab.ntt.co.jp
  http://git.postgresql.org/pg/commitdiff/2d1018ca56f5ddaf0bfb5b4d0133283f3e823301

- Use TSConfigRelationId in AlterTSConfiguration().  When we are altering a text
  search configuration, we are getting the tuple from pg_ts_config and using its
  OID, so use TSConfigRelationId when invoking any post-alter hooks and setting
  the object address.  Further, in the functions called from
  AlterTSConfiguration(), we're saving information about the command via
  EventTriggerCollectAlterTSConfig(), so we should be setting commandCollected
  to true.  Also add a regression test to test_ddl_deparse for ALTER TEXT SEARCH
  CONFIGURATION.  Author: Artur Zakirov, a few additional comments by me
  Discussion:
  https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru
  Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where it
  was introduced, and the fix for the ObjectAddressSet() call and setting
  commandCollected to true to 9.5 where those changes to ProcessUtilitySlow()
  were introduced.
  http://git.postgresql.org/pg/commitdiff/12bd7dd317e8f4346fb3507578aca790ede6ebea

- Fix tab completion in psql for ALTER DEFAULT PRIVILEGES.  When providing tab
  completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as
  possible options for completion after the GRANT or REVOKE.  Further, we accept
  FOR ROLE/IN SCHEMA at the same time and in either order, but the tab
  completion was only working for one or the other.  Lastly, we weren't using
  the actual list of allowed kinds of objects for default privileges for
  completion after the 'GRANT X ON' but instead were completeing to what 'GRANT
  X ON' supports, which isn't the ssame at all.  Address these issues by
  improving the forward tab-completion for ALTER DEFAULT PRIVILEGES and then
  constrain and correct how the tail completion is done when it is for ALTER
  DEFAULT PRIVILEGES.  Back-patch the forward/tail tab-completion to 9.6, where
  we made it easy to handle such cases.  For 9.5 and earlier, correct the
  initial tab-completion to at least be correct as far as it goes and then add a
  check for GRANT/REVOKE to only tab-complete when the GRANT/REVOKE is the start
  of the command, so we don't try to do tab-completion after we get to the
  GRANT/REVOKE part of the ALTER DEFAULT PRIVILEGES command, which is better
  than providing incorrect completions.  Initial patch for master and 9.6 by
  Gilles Darold, though I cleaned it up and added a few comments.  All bugs in
  the 9.5 and earlier patch are mine.  Discussion:
  https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc68b@dalibo.com
  http://git.postgresql.org/pg/commitdiff/f3fd531a51df2a73d8517a542e6999e0186e586b

- pg_dumpall: Include --verbose option in --help output.  The -v/--verbose
  option was not included in the output from --help for pg_dumpall even though
  it's in the pg_dumpall documentation and has apparently been around since
  pg_dumpall was reimplemented in C in 2002.  Fix that by adding it.  Pointed
  out by Daniel Westermann.  Back-patch to all supported branches.  Discussion:
  https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com
  http://git.postgresql.org/pg/commitdiff/86d216c77549e200b95bed487b6fb87d99a1e789

Joe Conway pushed:

- Improve dblink error message when remote does not provide it.  When dblink or
  postgres_fdw detects an error on the remote side of the connection, it will
  try to construct a local error message as best it can using libpq's
  PQresultErrorField(). When no primary message is available, it was bailing out
  with an unhelpful "unknown error". Make that message better and more style
  guide compliant. Per discussion on hackers.  Backpatch to 9.2 except
  postgres_fdw which didn't exist before 9.3.  Discussion:
  https://postgr.es/m/19872.1482338965%40sss.pgh.pa.us
  http://git.postgresql.org/pg/commitdiff/ea0aa9698cfa74bb04cf53d813924fe67f278c30

- Protect dblink from invalid options when using postgres_fdw server.  When
  dblink uses a postgres_fdw server name for its connection, it is possible for
  the connection to have options that are invalid with dblink (e.g.
  "updatable"). The recommended way to avoid this problem is to use dblink_fdw
  servers instead. However there are use cases for using postgres_fdw, and
  possibly other FDWs, for dblink connection options, therefore protect against
  trying to use any options that do not apply by using is_valid_dblink_option()
  when building the connection string from the options.  Back-patch to 9.3.
  Although 9.2 supports FDWs for connection info, is_valid_dblink_option() did
  not yet exist, and neither did postgres_fdw, at least in the postgres source
  tree. Given the lack of previous complaints, fixing that seems too
  invasive/not worth it.  Author: Corey Huinker Reviewed-By: Joe Conway
  Discussion:
  https://postgr.es/m/CADkLM%3DfWyXVEyYcqbcRnxcHutkP45UHU9WD7XpdZaMfe7S%3DRwA%40mail.gmail.com
  http://git.postgresql.org/pg/commitdiff/c4448683893bd37b59003603bc9075d362e81b5a

- Make dblink try harder to form useful error messages.  When libpq encounters a
  connection-level error, e.g. runs out of memory while forming a result, there
  will be no error associated with PGresult, but a message will be placed into
  PGconn's error buffer. postgres_fdw takes care to use the PGconn error message
  when PGresult does not have one, but dblink has been negligent in that regard.
  Modify dblink to mirror what postgres_fdw has been doing.  Back-patch to all
  supported branches.  Author: Joe Conway Reviewed-By: Tom Lane Discussion:
  https://postgr.es/m/02fa2d90-2efd-00bc-fefc-c23c00eb671e%40joeconway.com
  http://git.postgresql.org/pg/commitdiff/2f802d95b4904dbed3dfdca1b3a607cd085d2e20

- Improve RLS documentation with respect to COPY.  Documentation for pg_restore
  said COPY TO does not support row security when in fact it should say COPY
  FROM. Fix that.  While at it, make it clear that "COPY FROM" does not allow
  RLS to be enabled and INSERT should be used instead. Also that SELECT policies
  will apply to COPY TO statements.  Back-patch to 9.5 where RLS first appeared.
  Author: Joe Conway Reviewed-By: Dean Rasheed and Robert Haas Discussion:
  https://postgr.es/m/5744FA24.3030008%40joeconway.com
  http://git.postgresql.org/pg/commitdiff/0a85c102254b72ec7ce16bc504206a1a5c84bd76

Michael Meskes pushed:

- Fix buffer overflow on particularly named files and clarify documentation
  about output file naming.  Patch by Tsunakawa, Takayuki
  <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
  http://git.postgresql.org/pg/commitdiff/4032ef18d06aa7a3db515926ddebe8af04e533fe

Andres Freund pushed:

- Skip checkpoints, archiving on idle systems.  Some background activity (like
  checkpoints, archive timeout, standby snapshots) is not supposed to happen on
  an idle system. Unfortunately so far it was not easy to determine when a
  system is idle, which defeated some of the attempts to avoid redundant
  activity on an idle system.  To make that easier, allow to make individual WAL
  insertions as not being "important". By checking whether any important
  activity happened since the last time an activity was performed, it now is
  easy to check whether some action needs to be repeated.  Use the new facility
  for checkpoints, archive timeout and standby snapshots.  The lack of a
  facility causes some issues in older releases, but in my opinion the
  consequences (superflous checkpoints / archived segments) aren't grave enough
  to warrant backpatching.  Author: Michael Paquier, editorialized by Andres
  Freund Reviewed-By: Andres Freund, David Steele, Amit Kapila, Kyotaro
  HORIGUCHI Bug: #13685 Discussion:
  https://www.postgresql.org/message-id/20151016203031.3019.72930@wrigleys.postgresql.org
  https://www.postgresql.org/message-id/CAB7nPqQcPqxEM3S735Bd2RzApNqSNJVietAC=6kfkYv_45dKwA@mail.gmail.com
  Backpatch: -
  http://git.postgresql.org/pg/commitdiff/6ef2eba3f57f17960b7cd4958e18aa79e357de2f

== Pending Patches ==

Thomas Munro sent in a patch to add support for delta relations in AFTER
triggers to PL/PythonU.

Petr Jelínek sent in four more revisions of a patch to add logical replication.

Petr Jelínek sent in a patch to enable logical replication of data which was
there before logical replication was turned on.

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

Kyotaro HORIGUCHI sent in a patch to protect syscache from bloating with
negative cache entries.

Thomas Munro sent in another revision of a patch to allow measuring replay lag.

Beena Emerson sent in a patch to make wal segment size initdb configurable.

Ashutosh Sharma sent in another revision of a patch to add support for hash
index in pageinspect contrib module.

Michaël Paquier sent in two revisions of a patch to add tests for authentication
and pg_hba.conf.

Heikki Linnakangas sent in a patch to use the "plain:" prefix for plaintext
passwords stored in pg_authid.

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

Ants Aasma and Craig Ringer traded patches to fix an issue where the replication
slot xmin is not reset if HS feedback is turned off while the standby is shut down.

Kyotaro HORIGUCHI sent in another revision of a patch to implement asynchronous
query execution.

Heikki Linnakangas sent in another revision of a patch to add logical tape
pause/resume.

Ashutosh Sharma sent in a patch to create a pgstathashindex() function to get
hash index table statistics.

Dilip Kumar sent in another revision of a patch to implement parallel merge
join.

Andrea Urbani sent in a patch to add --custom-fetch-table and
--custom-fetch-value parameters to pg_dump.

Etsuro Fujita and Ashutosh Bapat traded patches to fix a FDW bug.

Artur Zakirov sent in another revision of a patch to output pg_ts_config_map
entries with pg_event_trigger_ddl_commands().

Michaël Paquier sent in a patch to fix a potential data loss of 2PC files.

Ashutosh Bapat sent in a patch to translate partition hierarchy into inheritance
hierarchy.

Craig Ringer sent in three revisions of a patch to introduce txid_status(bigint)
to get status of an xact.

Pavel Stěhule sent in another revision of a patch to add xmltable().

Kuntal Ghosh sent in a patch to reduce WALWriteLock contention.

Amul Sul sent in another revision of a patch to add a pg_background contrib
extension.

Amit Khandekar sent in a patch to implement parallel append.

Claudio Freire sent in a patch to prefetch buffers on backward scan and allow
using more than 1GB work mem in VACUUM.

Álvaro Herrera sent in two more revisions of a patch to implement indirect
indexes.

Craig Ringer sent in a patch to add a new CREATE_REPLICATION_SLOT option.

Daniel Vérité sent in another revision of a patch to improve some of the psql
variable hooks.

Jerry Yu sent in a patch to push down quals into EXCEPT.

Fabien COELHO sent in two more revisions of a patch to fix the handling of
compound/combined queries by pg_stat_statements.

Joel Jacobson sent in a patch to implement seconds resolution for wait_start.

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

Erik Rijkers sent in a patch to fix a typo in a comment in tablecmds.c.



pgsql-announce by date

Next:From: Bo PengDate: 2016-12-26 11:52:40
Subject: Pgpool-II 3.6.1, 3.5.5, 3.4.9, 3.3.13, 3.2.18 and 3.1.21 are now officially released.
Previous:From: Jehan-Guillaume de RorthaisDate: 2016-12-23 14:06:35
Subject: PostgreSQL Automatic Failover (PAF) v2.1.0 released

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