== PostgreSQL Weekly News - February 05 2017 ==

The first pgDay Israel 2017 will take place on March 2, 2017.  Registration is
open.
http://pgday.org.il/

Postgres Vision will take place in Boston, June 26 - 28, 2017.
the CfP is open until February 24, 2017 at CFP AT PostgresVision DOT com.
http://postgresvision.com/

== PostgreSQL Product News ==

Ora2Pg 18.0, a tool for migrating Oracle databases to PostgreSQL, released.
http://ora2pg.darold.net/

psqlODBC 09.06.0100 released.
https://odbc.postgresql.org/docs/release.html

PostGIS 2.2.5 and 2.3.2, the industry standard geographic information
system package for PostgreSQL, released.
http://postgis.net/2017/01/30/postgis-2.2.5/
http://postgis.net/2017/01/31/postgis-2.3.2/

== PostgreSQL Jobs for February ==

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

== PostgreSQL Local ==

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

PostgreSQL@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.
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 da...@fetter.org, German language
to p...@pgug.de, Italian language to p...@itpug.org.

== Applied Patches ==

Stephen Frost pushed:

- Handle ALTER EXTENSION ADD/DROP with pg_init_privs.  In commit 6c268df,
  pg_init_privs was added to track the initial privileges of catalog objects and
  extensions.  Unfortunately, that commit didn't include understanding of ALTER
  EXTENSION ADD/DROP, which allows the objects associated with an extension to
  be changed after the initial CREATE EXTENSION script has been run.  The result
  of this meant that ACLs for objects added through ALTER EXTENSION ADD were not
  recorded into pg_init_privs and we would end up including those ACLs in
  pg_dump when we shouldn't have.  This commit corrects that by making sure to
  have pg_init_privs updated when ALTER EXTENSION ADD/DROP is run, recording the
  permissions as they are at ALTER EXTENSION ADD time, and removing any if/when
  ALTER EXTENSION DROP is called.  This issue was pointed out by Moshe Jacobson
  as commentary on bug #14456 (which was actually a bug about versions prior to
  9.6 not handling custom ACLs on extensions correctly, an issue now addressed
  with pg_init_privs in 9.6).  Back-patch to 9.6 where pg_init_privs was
  introduced.
  
http://git.postgresql.org/pg/commitdiff/e54f75722c720b596ec5e72154cc899da199de5b

- test_pg_dump TAP test whitespace cleanup.  The formatting of the perl hashes
  used in the TAP tests for test_pg_dump was rather horribly inconsistent and
  made it more difficult than it really should have been to add new tests or
  adjust what tests are for what runs, etc.  Reformat to clean that all up.
  Whitespace-only changes.
  
http://git.postgresql.org/pg/commitdiff/fb94ca77f1400e236b00d432dccfbe4f1124971c

- test_pg_dump: perltidy cleanup.  As pointed out by Alvaro, we actually use
  perltidy on the perl scripts in the source tree, so go back to the results of
  a perltidy run for the test_pg_dump TAP script.  To make it look slightly less
  tragic, I changed most of the independent arguments into long-form single
  arguments (eg: -f file.sql changed to be --file=file.sql) to avoid having them
  confusingly split across lines due to perltidy.  Back-patch to 9.6, as the
  last patch was.
  
http://git.postgresql.org/pg/commitdiff/58da8334308c26107ebb7ee06c99589e14bd882b

- perltidy pg_dump TAP tests.  The pg_dump TAP tests have gotten pretty far from
  what perltidy thinks they should be, so fix that, and in passing use long-form
  argument names with arguments passed via "=" in a similar vein to 58da833.  No
  functional changes here, just whitespace and changing runs from "-f" to
  "--file=", and similar.
  
http://git.postgresql.org/pg/commitdiff/6af8b89adba16f97bee0d3b01256861e10d0e4f1

- pg_dump: Fix handling of ALTER DEFAULT PRIVILEGES.  In commit 23f34fa, we
  changed how ACLs were handled to use the new pg_init_privs catalog and to dump
  out the ACL commands as REVOKE+GRANT combinations instead of trying to REVOKE
  all rights always and then GRANT back just the ones which were in place.
  Unfortunately, the DEFAULT PRIVILEGES system didn't quite get the correct
  treatment with this change and ended up (incorrectly) only including positive
  GRANTs instead of both the REVOKEs and GRANTs necessary to preserve the
  correct privileges.  There are only a couple cases where such REVOKEs are
  possible because, generally speaking, there's few rights which exist on
  objects by default to be revoked.  Examples of REVOKEs which weren't being
  correctly preserved are when privileges are REVOKE'd from the creator/owner,
  like so: ALTER DEFAULT PRIVILEGES FOR ROLE myrole REVOKE SELECT ON TABLES FROM
  myrole; or when other default privileges are being revoked, such as EXECUTE
  rights granted to public for functions: ALTER DEFAULT PRIVILEGES FOR ROLE
  myrole REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC; Fix this by correctly working
  out what the correct REVOKE statements are (if any) and dump them out, just as
  we do for everything else.  Noticed while developing additional regression
  tests for pg_dump, which will be landing shortly.  Back-patch to 9.6 where the
  bug was introduced.
  
http://git.postgresql.org/pg/commitdiff/e2090d9d20d8091c9478a674d9c22fc8006909ce

Heikki Linnakangas pushed:

- Remove leftover reference to "indirect blocks" in comment.  Peter Geoghegan
  
http://git.postgresql.org/pg/commitdiff/dbeca61c3535af2613000c4492848ca6da8a902f

- Small fixes to the Perl scripts to create unicode conversion tables.  Add
  missing semicolons in UCS_to_* perl scripts.  For consistency, use
  "$hashref->{key}" style everywhere.  Kyotaro Horiguchi Discussion:
  
https://www.postgresql.org/message-id/20170130.153738.139030994.horiguchi.kyot...@lab.ntt.co.jp
  
http://git.postgresql.org/pg/commitdiff/bc1686f3f653d30847736f2b71d694b98ba5c31d

- Don't create "holes" in BufFiles, in the new logtape code.  The "Simplify tape
  block format" commit ignored the rule that blocks returned by
  ltsGetFreeBlock() must be written out in the same order, at least in the first
  write pass. To fix, relax that requirement, by making ltsWriteBlock() to
  detect if it's about to create a "hole" in the underlying BufFile, and fill it
  with zeros instead.  Reported, analysed, and reviewed by Peter Geoghegan.
  Discussion:
  
https://www.postgresql.org/message-id/cam3swzrwdntkhig0gyix_1muaypik3dv6-6542pye2iel-f...@mail.gmail.com
  
http://git.postgresql.org/pg/commitdiff/7ac4a389a7dbddaa8b19deb228f0a988e79c5795

- Replace isMD5() with a more future-proof way to check if pw is encrypted.  The
  rule is that if pg_authid.rolpassword begins with "md5" and has the right
  length, it's an MD5 hash, otherwise it's a plaintext password. The idiom has
  been to use isMD5() to check for that, but that gets awkward, when we add new
  kinds of verifiers, like the verifiers for SCRAM authentication in the pending
  SCRAM patch set. Replace isMD5() with a new get_password_type() function, so
  that when new verifier types are added, we don't need to remember to modify
  every place that currently calls isMD5(), to also recognize the new kinds of
  verifiers.  Also, use the new plain_crypt_verify function in passwordcheck, so
  that it doesn't need to know about MD5, or in the future, about other kinds of
  hashes or password verifiers.  Reviewed by Michael Paquier and Peter
  Eisentraut.  Discussion:
  
https://www.postgresql.org/message-id/2d07165c-1793-e243-a2a9-e45b624c7...@iki.fi
  
http://git.postgresql.org/pg/commitdiff/dbd69118c05d73969a1bd52ead6702c6e40b0fee

- Silence compiler warning.  Not all compilers understand that the elog(ERROR)
  never returns.  David Rowley
  
http://git.postgresql.org/pg/commitdiff/cb695ae993a38a0600a907154cfcc71285a9b9ef

- Add KOI8-U map files to Makefile.  These were left out by mistake back when
  support for KOI8-U encoding was added.  Extracted from Kyotaro Horiguchi's
  larger patch.
  
http://git.postgresql.org/pg/commitdiff/53dd2da257fb5904b087b97dd9c2867390d309c1

Tom Lane pushed:

- Update time zone data files to tzdata release 2016j.  DST law changes in
  northern Cyprus (new zone Asia/Famagusta), Russia (new zone Europe/Saratov),
  Tonga, Antarctica/Casey.  Historical corrections for Asia/Aqtau, Asia/Atyrau,
  Asia/Gaza, Asia/Hebron, Italy, Malta.  Replace invented zone abbreviation
  "TOT" for Tonga with numeric UTC offset; but as in the past, we'll keep
  accepting "TOT" for input.
  
http://git.postgresql.org/pg/commitdiff/308d8682740391cf6e94fdbadcdbbecfa02ea208

- Make psql reject attempts to set special variables to invalid values.
  Previously, if the user set a special variable such as ECHO to an unrecognized
  value, psql would bleat but store the new value anyway, and then fall back to
  a default setting for the behavior controlled by the variable.  This was
  agreed to be a not particularly good idea.  With this patch, invalid values
  result in an error message and no change in state.  (But this applies only to
  variables that affect psql's behavior; purely informational variables such as
  ENCODING can still be set to random values.) To do this, modify the API for
  psql's assign-hook functions so that they can return an OK/not OK result, and
  give them the responsibility for printing error messages when they reject a
  value.  Adjust the APIs for ParseVariableBool and ParseVariableNum to support
  the new behavior conveniently.  In passing, document the variable VERSION,
  which had somehow escaped that.  And improve the quite-inadequate commenting
  in psql/variables.c.  Daniel Vérité, reviewed by Rahila Syed, some further
  tweaking by me Discussion:
  https://postgr.es/m/7356e741-fa59-4146-a8eb-cf95fd6b21fb@mm
  
http://git.postgresql.org/pg/commitdiff/511ae628f31b4e791cd5c7836e46cb84dcf145fd

- Add a regression test script dedicated to exercising system views.  Quite a
  few of our built-in system views were not exercised anywhere in the regression
  tests.  This is perhaps not so exciting for the ones that are simple
  projections/joins of system catalogs, but for the ones that are wrappers for
  set-returning C functions, the omission translates directly to lack of test
  coverage for those functions.  In many cases, the reason for the omission is
  that the view doesn't have much to do with any specific SQL feature, so
  there's no natural place to test it.  To remedy that, invent a new script
  sysviews.sql that's dedicated to testing SRF-based views.  Move a couple of
  tests that did fit this charter into the new script, and add simple "count(*)"
  based tests of other views within the charter.  That's enough to ensure we at
  least exercise the main code path through the SRF, although it does little to
  prove that the output is sane.  More could be done here, no doubt, and I hope
  someone will think about how we can test these views more thoroughly.  But
  this is a starting point.  Discussion:
  https://postgr.es/m/19359.1485723...@sss.pgh.pa.us
  
http://git.postgresql.org/pg/commitdiff/d002f16c6ec38f76d1ee97367ba6af3000d441d0

- Invent pg_hba_file_rules view to show the content of pg_hba.conf.  This view
  is designed along the same lines as pg_file_settings, to wit it shows what is
  currently in the file, not what the postmaster has loaded as the active
  settings.  That allows it to be used to pre-vet edits before issuing SIGHUP.
  As with the earlier view, go out of our way to allow errors in the file to be
  reflected in the view, to assist that use-case.  (We might at some point
  invent a view to show the current active settings, but this is not that patch;
  and it's not trivial to do.) Haribabu Kommi, reviewed by Ashutosh Bapat,
  Michael Paquier, Simon Riggs, and myself Discussion:
  
https://postgr.es/m/cajrrpgerh4jiwpcxt1-46qxudmnp2qdrg9+-tek_xc8aphs...@mail.gmail.com
  
http://git.postgresql.org/pg/commitdiff/de16ab7238888b16825ad13f0bbe123632915e9b

- Simplify some long-obsolete code in hba.c's next_token().  next_token() oddly
  set its buffer space consumption limit to one before the last char position in
  the buffer, not the last as you'd expect.  The reason is there was once an
  ugly kluge to mark keywords by appending a newline to them, potentially
  requiring one more byte.  Commit e5e2fc842 removed that kluge, but failed to
  notice that the length limit could be increased.  Also, remove some vestigial
  handling of newline characters in the buffer.  That was left over from when
  this function read the file directly using getc().  Commit 7f49a67f9 changed
  it to read from a buffer, from which tokenize_file had already removed the
  only possible occurrence of newline, but did not simplify this function in
  consequence.  Also, ensure that we don't return with *lineptr set to someplace
  past the terminating '\0'; that would be catastrophic if a caller were to ask
  for another token from the same line.  This is just latent since no callers
  actually do call again after a "false" return; but considering that it was
  actually costing us extra code to do it wrong, we might as well make it
  bulletproof.  Noted while reviewing pg_hba_file_rules patch.
  
http://git.postgresql.org/pg/commitdiff/1e5a5d03da14ba9b734c6a2a1a822dcd8af110eb

- Make psql's \set display variables in alphabetical order.  "\set" with no
  arguments displays all defined variables, but it does so in the order that
  they appear in variables.c's list, which previously was mostly creation order.
  That makes the list ugly and hard to find things in, and it exposes some psql
  implementation details to users.  (For instance, ordinary variables will move
  to the bottom of the list if unset and set again, but variables that have
  hooks won't.) Fix that by keeping the list in alphabetical order at all times,
  which isn't much more complicated than breaking out of the insertion search
  loops once we reach an entry that should be after the one to be inserted.
  Discussion: https://postgr.es/m/31785.1485900...@sss.pgh.pa.us
  
http://git.postgresql.org/pg/commitdiff/c3e3844a92fe42109e4106314f7d229f784a7d0a

- Improve psql's behavior for \set and \unset of its control variables.  This
  commit improves on the results of commit 511ae628f in two ways: 1. It restores
  the historical behavior that "\set FOO" is interpreted as setting FOO to "on",
  if FOO is a boolean control variable.  We already found one test script that
  was expecting that behavior, and the psql documentation certainly does nothing
  to discourage people from assuming that would work, since it often says just
  "if FOO is set" when describing the effects of a boolean variable.  However,
  now this case will result in actually setting FOO to "on", not an empty
  string.  2. It arranges for an "\unset" of a control variable to set the value
  back to its default value, rather than becoming apparently undefined.  The
  control variables are also initialized that way at psql startup.  In
  combination, these things guarantee that a control variable always has a
  displayable value that reflects what psql is actually doing.  That is a pretty
  substantial usability improvement.  The implementation involves adding a
  second type of variable hook function that is able to replace a proposed new
  value (including NULL) with another one.  We could alternatively have
  complicated the API of the assign hook, but this way seems better since many
  variables can share the same substitution hook function.  Also document the
  actual behavior of these variables more fully, including covering assorted
  behaviors that were there before but never documented.  This patch also
  includes some minor cleanup that should have been in 511ae628f but was missed.
  Patch by me, but it owes a lot to discussions with Daniel Vérité.  Discussion:
  https://postgr.es/m/9572.1485821...@sss.pgh.pa.us
  
http://git.postgresql.org/pg/commitdiff/86322dc7e013b4062393dcbb74043db003e23ec5

- Provide CatalogTupleDelete() as a wrapper around simple_heap_delete().  This
  extends the work done in commit 2f5c9d9c9 to provide a more nearly complete
  abstraction layer hiding the details of index updating for catalog changes.
  That commit only invented abstractions for catalog inserts and updates,
  leaving nearby code for catalog deletes still calling the heap-level routines
  directly.  That seems rather ugly from here, and it does little to help if we
  ever want to shift to a storage system in which indexing work is needed at
  delete time.  Hence, create a wrapper function CatalogTupleDelete(), and
  replace calls of simple_heap_delete() on catalog tuples with it.  There are
  now very few direct calls of [simple_]heap_delete remaining in the tree.
  Discussion: https://postgr.es/m/462.1485902...@sss.pgh.pa.us
  
http://git.postgresql.org/pg/commitdiff/ab02896510e26e46b830c87eef2c03dd3c52c09e

- Fix CatalogTupleInsert/Update abstraction for case of shared indstate.  Add
  CatalogTupleInsertWithInfo and CatalogTupleUpdateWithInfo to let callers use
  the CatalogTupleXXX abstraction layer even in cases where we want to share the
  results of CatalogOpenIndexes across multiple inserts/updates for efficiency.
  This finishes the job begun in commit 2f5c9d9c9, by allowing some remaining
  simple_heap_insert/update calls to be replaced.  The abstraction layer is now
  complete enough that we don't have to export CatalogIndexInsert at all
  anymore.  Also, this fixes several places in which 2f5c9d9c9 introduced
  performance regressions by using retail CatalogTupleInsert or
  CatalogTupleUpdate even though the previous coding had been able to amortize
  CatalogOpenIndexes work across multiple tuples.  A possible future improvement
  is to arrange for the indexing.c functions to cache the CatalogIndexState
  somewhere, maybe in the relcache, in which case we could get rid of
  CatalogTupleInsertWithInfo and CatalogTupleUpdateWithInfo again.  But that's a
  task for another day.  Discussion:
  https://postgr.es/m/27502.1485981...@sss.pgh.pa.us
  
http://git.postgresql.org/pg/commitdiff/aedd554f84bb3cedb32e6e2a954a70537a4da6b9

- Fix mishandling of tSRFs at different nesting levels.  Given a targetlist like
  "srf(x), f(srf(x))", split_pathtarget_at_srfs() decided that it needed two
  levels of ProjectSet nodes, failing to notice that the two SRF calls are
  textually equal().  Because of that, setrefs.c would convert the upper
  ProjectSet's tlist to "Var1, f(Var1)" (where Var1 represents a reference to
  the srf(x) output of the lower ProjectSet).  This triggered an assertion in
  nodeProjectSet.c complaining that it found no SRFs to evaluate, as reported by
  Erik Rijkers.  What we want in such a case is to evaluate srf(x) only once and
  use a plain Result node to compute "Var1, f(Var1)"; that gives results similar
  to what previous versions produced, whereas allowing srf(x) to be evaluated
  again in an upper ProjectSet would square the number of rows emitted.
  Furthermore, even if the SRF calls aren't textually identical, we want them to
  be evaluated in lockstep, because that's what happened in the old
  implementation.  But split_pathtarget_at_srfs() got this completely wrong,
  using two levels of ProjectSet for a case like "srf(x), f(srf(y))".  Hence,
  rewrite split_pathtarget_at_srfs() from the ground up so that it groups SRFs
  according to the depth of nesting of SRFs in their arguments.  This is pretty
  much how we envisioned that working originally, but I blew it when it came to
  implementation.  In passing, optimize the case of target == input_target,
  which I noticed is not only possible but quite common.  Discussion:
  https://postgr.es/m/dcbd2853c05d22088766553d60dc7...@xs4all.nl
  
http://git.postgresql.org/pg/commitdiff/c82d4e658eff287846fe6243966d110ff4ae9025

- Fix placement of initPlans when forcibly materializing a subplan.  If we
  forcibly place a Material node atop a finished subplan, we need to move any
  initPlans attached to the subplan up to the Material node, in order to keep
  SS_finalize_plan() happy.  I'd figured this out in commit 7b67a0a49 for the
  case of materializing a cursor plan, but out of an abundance of caution, I put
  the initPlan movement hack at the call site for that case, rather than inside
  materialize_finished_plan().  That was the wrong thing, because it turns out
  to also be necessary for the only other caller of materialize_finished_plan(),
  ie subselect.c.  We lacked any test cases that exposed the mistake, but
  bug#14524 from Wei Congrui shows that it's possible to get an initPlan
  reference into the top tlist in that case too, and then SS_finalize_plan()
  complains.  Hence, move the hack into materialize_finished_plan().  In HEAD,
  also relocate some recently-added tests in subselect.sql, which I'd
  unthinkingly dropped into the middle of a sequence of related tests.  Report:
  https://postgr.es/m/20170202060020.1400.89...@wrigleys.postgresql.org
  
http://git.postgresql.org/pg/commitdiff/555494d1bc119173bbf712940da823303644d4de

- Avoid improbable null pointer dereference in pgpassfileWarning().  Coverity
  complained that we might pass a null pointer to strcmp() if PQresultErrorField
  were to return NULL.  That shouldn't be possible, since the server is supposed
  to always provide some SQLSTATE or other in an error message.  But we usually
  defend against such hazards, and it only takes a little more code to do so
  here.  There's no good reason to think this is a live bug, so no back-patch.
  
http://git.postgresql.org/pg/commitdiff/8ac0365c22f20dcd2a6b6752b95b665ada83e858

- Clean up psql's behavior for a few more control variables.  Modify FETCH_COUNT
  to always have a defined value, like other control variables, mainly so it
  will always appear in "\set" output.  Add hooks to force HISTSIZE to be
  defined and require it to have an integer value.  (I don't see any point in
  allowing it to be set to non-integral values.) Add hooks to force IGNOREEOF to
  be defined and require it to have an integer value.  Unlike the other cases,
  here we're trying to be bug-compatible with a rather bogus externally-defined
  behavior, so I think we need to continue to allow "\set IGNOREEOF whatever".
  Fix it so that the substitution hook silently replace non-numeric values with
  "10", so that the stored value always reflects what we're really doing.  Add a
  dummy assign hook for HISTFILE, just so it's always in variables.c's list.  We
  can't require it to be defined always, because that would break the
  interaction with the PSQL_HISTORY environment variable, so there isn't any
  change in visible behavior here.  Remove tab-complete.c's private list of
  known variable names, since that's really a maintenance nuisance.  Given the
  preceding changes, there are no control variables it won't show anyway.  This
  does mean that if for some reason you've unset one of the status variables
  (DBNAME, HOST, etc), that variable would not appear in tab completion for
  \set.  But I think that's fine, for at least two reasons: we shouldn't be
  encouraging people to use those variables as regular variables, and if someone
  does do so anyway, why shouldn't it act just like a regular variable?  Remove
  ugly and no-longer-used-anywhere GetVariableNum().  In general, future
  additions of integer-valued control variables should follow the paradigm of
  adding an assign hook using ParseVariableNum(), so there's no reason to expect
  we'd need this again later.  Discussion:
  https://postgr.es/m/17516.1485973...@sss.pgh.pa.us
  
http://git.postgresql.org/pg/commitdiff/fd6cd698031d3dbeccafde49a8b118cb840312aa

- Fix a bunch more portability bugs in commit 08bf6e529.  It seems like somebody
  used a dartboard while choosing integer widths for the various values taken
  and returned by these functions ... and then threw a fresh set of darts while
  writing the SQL declarations.  This patch brings the C code into line with
  what the SQL declarations say, which is enough to make it not dump core on the
  particular 32-bit machine I'm testing on.  But I think we could do with
  another round of looking at what the datum widths *should* be.  For instance,
  it's not all that sensible that hash_bitmap_info decided to use int64 to
  represent a BlockNumber input when get_raw_page doesn't do it that way.
  There's also a remaining problem that the expected outputs from the test
  script are platform-dependent, but I'll leave that issue for somebody else.
  Per buildfarm.
  
http://git.postgresql.org/pg/commitdiff/c6eeb67dcc3b3f7aa94335e18a1075863d808a7c

- In pageinspect/hashfuncs.c, avoid crashes on alignment-picky machines.  On
  machines with MAXALIGN = 8, the payload of a bytea is not maxaligned, since it
  will start 4 bytes into a palloc'd value.  On alignment-picky hardware, this
  will cause failures in accesses to 8-byte-wide values within the page.  We
  already encountered this problem when we introduced GIN index inspection
  functions, and fixed it in commit 84ad68d64.  Make use of the same function
  for hash indexes.  A small difficulty is that up to now contrib/pageinspect
  has not shared any functions at all across files.  To support that, introduce
  a common header file "pageinspect.h" for the module.  Also, move
  get_page_from_raw() out of ginfuncs.c, where it didn't especially belong, and
  put it in rawpage.c which seems a more natural home.  Per buildfarm.
  Discussion: https://postgr.es/m/17311.1486134...@sss.pgh.pa.us
  
http://git.postgresql.org/pg/commitdiff/14e9b18fed289e483ed28daec60fdab95da9cc48

- First-draft release notes for 9.6.2.  As usual, the release notes for other
  branches will be made by cutting these down, but put them up for community
  review first.
  
http://git.postgresql.org/pg/commitdiff/9863017b87f3592ff663d03fc663a4f1f8fdb8b2

Peter Eisentraut pushed:

- Additional test coverage for sequences.  Reviewed-by: Michael Paquier
  <michael.paqu...@gmail.com>
  
http://git.postgresql.org/pg/commitdiff/d711532b2eb70cf2f56d95efcc608d474266d769

- Fix sequence test in cs_CZ locale.  Rename some objects so that sorted output
  becomes less locale-dependent.
  
http://git.postgresql.org/pg/commitdiff/46aae5949f56580281a0f487c785c745d8856a04

- doc: Document result set of CREATE_REPLICATION_SLOT.  From: Marko Tiikkaja
  <ma...@joh.to>
  
http://git.postgresql.org/pg/commitdiff/ecb814b5cef4971e50ee177eff320d416aa0b882

- doc: Add missing include in example code.  It's not broken because the header
  file is included via other headers, but for better style we should be more
  explicit.  Reported-by: mthrockmor...@hme.com
  
http://git.postgresql.org/pg/commitdiff/aa09b9dcd57cbf18516332bf8310c12ef6f83715

Álvaro Herrera pushed:

- Tweak catalog indexing abstraction for upcoming WARM.  Split the existing
  CatalogUpdateIndexes into two different routines, CatalogTupleInsert and
  CatalogTupleUpdate, which do both the heap insert/update plus the index
  update.  This removes over 300 lines of boilerplate code all over
  src/backend/catalog/ and src/backend/commands.  The resulting code is much
  more pleasing to the eye.  Also, by encapsulating what happens in detail
  during an UPDATE, this facilitates the upcoming WARM patch, which is going to
  add a few more lines to the update case making the boilerplate even more
  boring.  The original CatalogUpdateIndexes is removed; there was only one use
  left, and since it's just three lines, we can as well expand it in place
  there.  We could keep it, but WARM is going to break all the UPDATE
  out-of-core callsites anyway, so there seems to be no benefit in doing so.
  Author: Pavan Deolasee Discussion:
  
https://www.postgr.es/m/CABOikdOcFYSZ4vA2gYfs=m2cdxzxx4qgheeiw3fu9pcfkhl...@mail.gmail.com
  
http://git.postgresql.org/pg/commitdiff/2f5c9d9c9cec436e55847ec580606d7e88067df6

Robert Haas pushed:

- Move comment about test slightly closer to test.  The addition of a
  TestForOldSnapshot() call here has made the referent of this comment slightly
  less clear, so move the comment to compensate.  Amit Kapila (as part of the
  parallel index scan patch)
  
http://git.postgresql.org/pg/commitdiff/8a815e3fc318b441a5e8a37e4129660d81e1e012

- Refactor other replication commands to use DestRemoteSimple.  Commit
  a84069d9350400c860d5e932b50dfd337aa407b0 added a new type of DestReceiver to
  avoid duplicating the existing code for the SHOW command, but it turns out we
  can leverage that new DestReceiver type in a few more places, saving some
  code.  Michael Paquier, reviewed by Andres Freund and by me.  Discussion:
  
http://postgr.es/m/CAB7nPqSdFOQC0evc0r1nJeQyGBqjBrR41MC4rcMqUUpoJaZbtQ%40mail.gmail.com
  Discussion:
  
http://postgr.es/m/cab7npqt2k4xft1jgquffbjsoc-nukxg5qbduchpmbk6xi1k...@mail.gmail.com
  
http://git.postgresql.org/pg/commitdiff/bbd8550bce146f86e5e883f1232292a975c314fb

- Increase upper bound for bgwriter_lru_maxpages.  There is no particularly good
  reason to limit this value to 1000, so increase the limit to INT_MAX / 2, the
  same limit we use for shared_buffers.  It's not clear how much practical
  effect larger settings will have, but there seems no harm in letting people
  try it.  Jim Nasby, less a comment change I stripped out.  Discussion:
  http://postgr.es/m/f6e58a22-030b-eb8a-5457-f62fb08d7...@bluetreble.com
  
http://git.postgresql.org/pg/commitdiff/14ca9abfbe4643408ad6ed3279f2f6366cafb3f1

- pageinspect: Support hash indexes.  Patch by Jesper Pedersen and Ashutosh
  Sharma, with some error handling improvements by me.  Tests from Peter
  Eisentraut.  Reviewed by Álvaro Herrera, Michael Paquier, Jesper Pedersen,
  Jeff Janes, Peter Eisentraut, Amit Kapila, Mithun Cy, and me.  Discussion:
  http://postgr.es/m/e2ac6c58-b93f-9dd9-f4e6-d6d30add7...@redhat.com
  
http://git.postgresql.org/pg/commitdiff/08bf6e529587e1e9075d013d859af2649c32a511

- pageinspect: Try to fix some bugs in previous commit.  Commit
  08bf6e529587e1e9075d013d859af2649c32a511 seems not to have used the correct
  *GetDatum and PG_GETARG_* macros for the SQL types in some cases, and some of
  the SQL types seem to have been poorly chosen, too.  Try to fix it.  I'm not
  sure if this is the reason why the buildfarm is currently unhappy with this
  code, but it seems like a good place to start.  Buildfarm unhappiness reported
  by Tom Lane.
  
http://git.postgresql.org/pg/commitdiff/ed807fda6d5102537daa5d725e716555cbc49f44

- pageinspect: Remove platform-dependent values from hash tests.  Per a report
  from Tom Lane, the ffactor reported by hash_metapage_info and the free_size
  reported by hash_page_stats vary by platform.  Ashutosh Sharma and Robert Haas
  
http://git.postgresql.org/pg/commitdiff/29e312bc1301061ae9f897ff39f3b230c421a5fb

- pgstattuple: Add pgstathashindex.  Since pgstattuple v1.5 hasn't been released
  yet, no need for a new extension version.  The new function exposes statistics
  about hash indexes similar to what other pgstatindex functions return for
  other index types.  Ashutosh Sharma, reviewed by Kuntal Ghosh.  Substantial
  further revisions by me.
  
http://git.postgresql.org/pg/commitdiff/e759854a09d49725a9519c48a0d71a32bab05a01

- pageinspect: More type-sanity surgery on the new hash index code.  Uniformly
  expose unsigned quantities using the next-wider signed integer type (since we
  have no unsigned types at the SQL level).  At the SQL level, this results a
  change to report itemoffset as int4 rather than int2.  Also at the SQL level,
  report one value that is an OID as type oid.  Under the hood, uniformly use
  macros that match the SQL output type as to both width and signedness.
  
http://git.postgresql.org/pg/commitdiff/871ec0e33673ad9719760131b71a02ecbda82e12

- Improve grammar of message about two-phase state files.  When there's only one
  two-phase state file, there's also only one long-running prepared transaction.
  Adjust the message text accordingly.  Nikhil Sontakke Discussion:
  
http://postgr.es/m/CAMGcDxcmR_DWZXXndGoPzVQx=B17A5=RviEA1qNaF=fwly5...@mail.gmail.com
  
http://git.postgresql.org/pg/commitdiff/38c363adf497c0a05858dc00bc49ea42023bd572

- Remove redundant comment.  Rafia Sabih
  
http://git.postgresql.org/pg/commitdiff/6f4b4ceefa673dff6563d2d17e2039248f16fe1d

Andrew Dunstan pushed:

- Don't count background workers against a user's connection limit.  Doing so
  doesn't seem to be within the purpose of the per user connection limits, and
  has particularly unfortunate effects in conjunction with parallel queries.
  Backpatch to 9.6 where parallel queries were introduced.  David Rowley,
  reviewed by Robert Haas and Albe Laurenz.
  
http://git.postgresql.org/pg/commitdiff/f1169ab501ce90e035a7c6489013a1d4c250ac92

Noah Misch pushed:

- Code review for avoidance of direct cross-module links.  Remove $(pkglibdir)
  from $(rpathdir), since commits d51924be886c2a05e691fa05b16cb6b30ab8370f and
  eda04886c1e048d695728206504ab4198462168e removed direct linkage to objects
  stored there.  Users are unlikely to notice the difference.  Accompany every
  $(python_libspec) with $(python_additional_libs); this doesn't fix a
  demonstrated bug, but it might do so on rare Python configurations.  With
  these changes, AIX ceases to be a special case.
  
http://git.postgresql.org/pg/commitdiff/acd73ad1a17f7aed6a914dd9c331f1043d89988d

Fujii Masao pushed:

- Be sure to release LogicalRepLauncherLock in DROP SUBSCRIPTION command.
  Previously DROP SUBSCRIPTION command forgot to release the lock at all.
  Original patches by Kyotaro Horiguchi and Michael Paquier, but I didn't use
  them.  Discussion:
  http://postgr.es/m/20170201.173623.66249355.horiguchi.kyot...@lab.ntt.co.jp
  
http://git.postgresql.org/pg/commitdiff/39b8cc991fe31ee8df8b0fee467bbd9800fcc1c5

== Pending Patches ==

Takayuki Tsunakawa sent in another revision of a patch to support huge pages on
Windows.

Nikita Glukhov sent in three revisions of a patch to fix a bug in SP-GiST
box_ops.

Kyotaro HORIGUCHI sent in two more revisions of a patch to implement character
conversion with radix trees.

Alexander Korotkov sent in another revision of a patch to cacheline align
PGXACT.

Nikita Glukhov sent in a patch to implement kNN searches for SP-GiST.

Michaël Paquier sent in another revision of a patch to allow interrupts on
waiting standby.

Rushabh Lathia sent in a patch to extend the existing wait event infrastructure
to implement the wait events for the disk I/O.

Etsuro Fujita sent in another revision of a patch to push down more full joins
to the PostgreSQL FDW.

Michaël Paquier sent in two more revisions of a patch to refactor replication
commands using printsimple.

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

Daisuke Higuchi and Ashutosh Bapat traded patches to fix a bug where PQgetResult
is not called until PQgetResult has returned a null pointer.

Heikki Linnakangas sent in two more revisions of a patch to fix an issue which
produced a deadlock in XLogInsert on AIX.

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

Tomas Vondra sent in another revision of a patch to implement multivariate
statistics.

Amit Kapila sent in two more revisions of a patch to implement parallel index
scans.

Claudio Freire sent in two more revisions of a patch to enable VACUUM to use
more than 1GB of work_mem.

Pavan Deolasee, Álvaro Herrera, and Tom Lane traded patches to fix an issue
where CREATE INDEX CONCURRENTLY could cause index corruption.

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

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

Michaël Paquier sent in a patch to forbid newline and carriage return characters
in database and role names, and ensure clean-up of data directory even with
restricted path applied.

Haribabu Kommi sent in another revision of a patch to add a macaddr 64 bit
(EUI-64) datatype.

Peter Eisentraut sent in another revision of a patch to implement a set of
SEQUENCE data types.

Pavan Deolasee sent in three more revisions of a patch to implement WARM.

Kyotaro HORIGUCHI sent in two more revisions of a patch to fix a bug in physical
replication slots.

Kyotaro HORIGUCHI sent in two more revisions of a patch to enable logical
replication between databases with different encodings.

Dilip Kumar sent in two more revisions of a patch to implement parallel bitmap
heap scan.

Pavel Stěhule sent in another revision of a patch to enable PL/pgsql to force a
custom or generic plan.

Anastasia Lubennikova sent in a patch to allow casting from the appropriate
jsonb objects to numeric, int, float, bool.

Dagfinn Ilmari Mannsåker sent in two revisions of a patch to add tab completion
for DEALLOCATE.

Rushabh Lathia sent in two more revisions of a patch to implement Gather Merge.

Nikhil Sontakke sent in two more revisions of a patch to speed up two-phase
transactions.

David Rowley sent in a patch to fix a compiler warning in dbd69118.

Michaël Paquier sent in two revisions of a patch to provide list of
subscriptions and publications in psql's completion.

Corey Huinker sent in three more revisions of a patch to add \if and friends to
psql.

Peter Moser sent in another revision of a patch to add temporal query
primitives.

Alexey Bashtanov sent in a patch to optimize the query used to produce
information_schema.constraint_column_usage.

Simon Riggs sent in a patch to introduce the concept of a "superowner".

Andres Freund sent in a patch to implement a basic lockless single producer,
multiple consumer ringbuffer, and a rewrite of the bgwriter to use same.

Kyotaro HORIGUCHI sent in another revision of a patch to refactor tab completion
in psql and use same to add some tab completion features.

Amit Langote sent in a patch to improve the documentation about partitioned
tables.

Andreas Karlsson sent in a patch to add psql tab completion for \help 
DROP|ALTER.

Alexander Korotkov sent in a patch to implement low-level locking on PowerPC in
assembly.

Boris Muratshin sent in a patch to implement 3D Z-curve spatial indexes.

Fabien COELHO sent in another revision of a patch to add more operators and
functions to pgbench.

Alexander Korotkov sent in a patch to re-add strategy to PinBuffer.

Masahiko Sawada sent in a patch to fix a typo in a variable name in launcher.c.

Noah Misch sent in a patch to ignore tablespace ACLs when ignoring schema ACLs.

Brandur Leach sent in another revision of a patch to implement SortSupport for
macaddr data type.



-- 
Sent via pgsql-announce mailing list (pgsql-announce@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-announce

Reply via email to