== PostgreSQL Weekly News - April 17 2016 ==

== PostgreSQL Weekly News - April 17 2016 ==

PostgreSQL Session will be held on September 22th, 2016, in Lyon,
France.  The submission deadline is May 20, 2016. Send proposals to
call-for-paper AT postgresql-sessions DOT org.

== PostgreSQL Product News ==

Amazon RDS for PostgreSQL now supports major version 9.5.
https://aws.amazon.com/about-aws/whats-new/2016/04/rds-postgresql-9-5-support/

== PostgreSQL Jobs for April ==

http://archives.postgresql.org/pgsql-jobs/2016-04/

== PostgreSQL Local ==

PGConf US 2016 will take place April 18-20, 2016 in NYC.  Registration
is open.
http://www.pgconf.us/2016/

LinuxFest Northwest will take place April 23-24, 2016 at Bellingham
Technical College in Bellingham, Washington, USA.
http://www.linuxfestnorthwest.org/2016/

FOSS4G NA, will be held May 2-5, 2016 in Raleigh, North Carolina.
https://2016.foss4g-na.org/

PGCon 2016 will be held May 17-21, 2016 in Ottawa.
http://www.pgcon.org/

This year's Swiss PGDay will be held on June 24, 2016 at the
University of Applied Sciences in Rapperswil (Switzerland).
http://www.pgday.ch/

"5432 ... Meet us!", will take place in Milan, Italy on June 28-29, 2016.
Registration is open.
http://5432meet.us/

PG Day UK 2016 will be 5th July 2016.
http://www.pgconf.uk/

PgConf Silicon Valley 2016 will be held on November 14-16, 2016.
http://www.pgconfsv.com/

== 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@fetter.org, German language
to pwn@pgug.de, Italian language to pwn@itpug.org.  Spanish language
to pwn@arpug.com.ar.

== Applied Patches ==

Fujii Masao pushed:

- Use ereport(ERROR) instead of Assert() to emit syncrep_parser error.
  The existing code would either Assert or generate an invalid
  SyncRepConfig variable, neither of which is desirable. A regular
  error should be thrown instead.  This commit silences compiler
  warning in non assertion-enabled builds.  Per report from Jeff
  Janes.  Suggested fix by Tom Lane.
  http://git.postgresql.org/pg/commitdiff/0038c1e2181b520a9307aae6587e110468072392

- Remove unused function GetOldestWALSendPointer from walsender code.
  That unused function was introduced as a sample because synchronous
  replication or replication monitoring tools might need it in the
  future.  Recently commit 989be08 added the function
  SyncRepGetOldestSyncRecPtr which provides almost the same
  functionality for multiple synchronous standbys feature. So it's
  time to remove that unused sample function.  This commit does that.
  Branch ------ master Details -------
  http://git.postgresql.org/pg/commitdiff/46d73e0d65eef19e25bb0d31f1e5c23ff40a3444
  http://git.postgresql.org/pg/commitdiff/cfe96ae24c97ff376157c48ccd5ca6d3938632be

- Fix duplicated index entry in doc.  Commit cfe96ae corrected the
  name of pg_logical_emit_message() in its index entry. But this typo
  fix caused duplicated index entry because there was another index
  entry for the function.  Spotted by Tom Lane.
  http://git.postgresql.org/pg/commitdiff/c8cb7453233b31a177b08a3b2bdac4c31508dc00

- Make regression test for multiple synchronous standbys more stable.
  The regression test checks whether the output of pg_stat_replication
  is expected or not after changing synchronous_standby_names and
  reloading the configuration file. Regarding this test logic,
  previously there was a timing issue which made the test result
  unstable. That is, pg_stat_replication could return unexpected
  result during small window after the configuration file was reloaded
  before new setting value took effect, and which made the test fail.
  This commit changes the test logic so that it uses a loop with a
  timeout to give some room for the test to pass. Now the test fails
  only when pg_stat_replication keeps returning unexpected result for
  30 seconds.  Michael Paquier
  http://git.postgresql.org/pg/commitdiff/36c1c91604cee164c6487afb99508f7ff8737b96

Peter Eisentraut pushed:

- cpluspluscheck: Update include path.  Some things in
  src/include/fe_utils require libpq headers, so add libpq's include
  path to the command line used here.
  http://git.postgresql.org/pg/commitdiff/ee5dbc8173d8f434a467380bfd218ef6f91a8e31

- Add directory created during build to gitignore.
  http://git.postgresql.org/pg/commitdiff/29ca231b83a142ea1633e7c496619accb7dd9e4f

- Fix whitespace.
  http://git.postgresql.org/pg/commitdiff/d8ed83cd7fd1082f60a5b9897b62216f6b3e2587

- Fix whitespace.
  http://git.postgresql.org/pg/commitdiff/70715e6a600f1652a04b4e698dad3c7d6bff6bdb

- psql: Add new gettext trigger.
  http://git.postgresql.org/pg/commitdiff/c3136876734b31ce50018f39c87b00145a8c7c33

- doc: Add missing parentheses.  From: Alexander Law
  <exclusion@gmail.com>
  http://git.postgresql.org/pg/commitdiff/d2de44c2ce5c697a2de8089fb377816b2387107a

- doc: Change some "user" to "role" for consistency in the section.
  suggested by Johannes Choo
  http://git.postgresql.org/pg/commitdiff/5fdda1ceab35311367ed0dbb283cd8aea896e49b

- doc: Markup improvement
  http://git.postgresql.org/pg/commitdiff/efb25e56d8a43917bcadfe3904691b1e1cdbbe20

Tom Lane pushed:

- Fix missing "volatile" in PLy_output().  Commit 5c3c3cd0a3046339
  plastered "volatile" on a bunch of variables in PLy_output(), but
  removed the one that actually mattered, ie the one on "oldcontext".
  This allows some versions of clang to generate code in which
  "oldcontext" has been trashed when control reaches the PG_CATCH
  block.  Per buildfarm member tick.
  http://git.postgresql.org/pg/commitdiff/81ba9348d85fdf87e84cc02112933b592845bda2

- Fix freshly-introduced PL/Python portability bug.  It turns out that
  those PyErr_Clear() calls I removed from plpy_elog.c in
  7e3bb080387f4143 et al were not quite as random as they appeared:
  they mask a Python 2.3.x bug.  (Specifically, it turns out that
  PyType_Ready() can fail if the error indicator is set on entry, and
  PLy_traceback's fetch of frame.f_code may be the first operation in
  a session that requires the "frame" type to be readied.  Ick.)  Put
  back the clear call, but in a more centralized place closer to what
  it's protecting, and this time with a comment warning what it's
  really for.  Per buildfarm member prairiedog.  Although prairiedog
  was only failing on HEAD, it seems clearly possible for this to
  occur in older branches as well, so back-patch to 9.2 the same as
  the previous patch.
  http://git.postgresql.org/pg/commitdiff/1d2f9de38d18152f83cf570581cebac0733ff504

- Fix two places that thought Windows64 is indicated by WIN64 macro.
  Everyplace else thinks it's _WIN64, so make these places fall in
  line.  The pg_regress.c usage is not going to result in any change
  in behavior, only suppressing (or not) a compiler warning about
  downcasting HANDLEs.  So there seems no need for back-patching
  there.  The libpq/win32.mak usage might represent an actual bug, if
  anyone were using this script to build for Windows64, which perhaps
  nobody is.  Given the lack of field complaints, no back-patch here
  either.  pg_regress.c problem found by Christian Ullrich, the other
  by me.
  http://git.postgresql.org/pg/commitdiff/b0e40d189325dc7a54d2546245e766f8c47a7c8d

- Fix _SPI_execute_plan() for CREATE TABLE IF NOT EXISTS foo AS ...
  When IF NOT EXISTS was added to CREATE TABLE AS, this logic didn't
  get the memo, possibly resulting in an Assert failure.  It looks
  like there would have been no ill effects in a non-Assert build,
  though.  Back-patch to 9.5 where the IF NOT EXISTS option was added.
  Stas Kelvich
  http://git.postgresql.org/pg/commitdiff/39c283e498de1bb7c3d5beadfffcf3273ae8cc27

- Remove unnecessary definition of _WIN64 in libpq/win32.mak.  In
  commit b0e40d189325dc7a54d2546245e766f8c47a7c8d, I should have just
  removed the /D switch defining WIN64.  The reason the code worked
  before is that all Windows64 compilers automatically predefine
  _WIN64.  Perhaps at one time we had code that depended on WIN64
  being defined, but it's long gone, and we should not encourage any
  reappearance.  Per discussion with Christian Ullrich.
  http://git.postgresql.org/pg/commitdiff/e7bcde8ca0d376d9d23d61855baf67122a66c76a

- In generic WAL application and replay, ensure page "hole" is always
  zero.  The previous coding could allow the contents of the "hole"
  between pd_lower and pd_upper to diverge during replay from what it
  had been when the update was originally applied.  This would pose a
  problem if checksums were in use, and in any case would complicate
  forensic comparisons between master and slave servers.  So force the
  "hole" to contain zeroes, both at initial application of a
  generically-logged action, and at replay.  Alexander Korotkov,
  adjusted slightly by me
  http://git.postgresql.org/pg/commitdiff/bdf7db81921deb99fd9d489cbcc635906c89e215

- Improve API of GenericXLogRegister().  Rename this function to
  GenericXLogRegisterBuffer() to make it clearer what it does, and
  leave room for other sorts of "register" actions in future.  Also,
  replace its "bool isNew" argument with an integer flags argument, so
  as to allow adding more flags in future without an API break.
  Alexander Korotkov, adjusted slightly by me
  http://git.postgresql.org/pg/commitdiff/5713f03973e26ad6df6df5ac8b9efa0123d68062

- Improve coding of column-name parsing in psql's new crosstabview.c.
  Coverity complained about this code, not without reason because it
  was rather messy.  Adjust it to not scribble on the passed string;
  that adds one malloc/free cycle per column name, which is going to
  be insignificant in context.  We can actually const-ify both the
  string argument and the PGresult.  Daniel Verité, with some further
  cleanup by me
  http://git.postgresql.org/pg/commitdiff/7a5f8b5c59033ac153963f98b9109be9529a824a

- Redefine create_upper_paths_hook as being invoked once per upper
  relation.  Per discussion, this gives potential users of the hook
  more flexibility, because they can build custom Paths that implement
  only one stage of upper processing atop core-provided Paths for
  earlier stages.
  http://git.postgresql.org/pg/commitdiff/f1f01de145d0aaca80e6cf8b2ccb7e7f4ed1ad02

- Improve documentation for \crosstabview.  Fix misleading syntax
  summary (there cannot be a space between colH and scolH).  Provide a
  link from the existing crosstab() function's documentation to
  \crosstabview.  Copy-edit the command's description.  Christoph Berg
  and Tom Lane
  http://git.postgresql.org/pg/commitdiff/85e004707715f5ee7a6bfc3d03d0fbc837fb2432

- Fix assorted portability issues with using msync() for data
  flushing.  Commit 428b1d6b29ca599c5700d4bc4f4ce4c5880369bf
  introduced the use of msync() for flushing dirty data from the
  kernel's file buffers.  Several portability issues were overlooked,
  though: * Not all implementations of mmap() think that nbytes == 0
  means "map the whole file".  To fix, use lseek() to find out the
  true length.  Fix callers of pg_flush_data to be aware that nbytes
  == 0 may result in trashing the file's seek position.  * Not all
  implementations of mmap() will accept partial-page mmap requests.
  To fix, round down the length request to whatever sysconf() says the
  page size is.  (I think this is OK from a portability standpoint,
  because sysconf() is required by SUS v2, and we aren't trying to
  compile this part on Windows anyway.  Buildfarm should let us know
  if not.) * On 32-bit machines, the file size might exceed the
  available free address space, or even exceed what will fit in
  size_t.  Check for the latter explicitly to avoid passing a false
  request size to mmap().  If mmap fails, silently fall through to the
  next implementation method, rather than bleating to the postmaster
  log and giving up.  * mmap'ing directories fails on some platforms,
  and even if it works, msync'ing the directory is quite unlikely to
  help, as for that matter are the other flush implementations.  In
  pre_sync_fname(), just skip flush attempts on directories.  In
  passing, copy-edit the comments a bit.  Stas Kelvich and myself
  http://git.postgresql.org/pg/commitdiff/fa11a09fed2b6f483231608866a682ee3a376277

- Widen amount-to-flush arguments of FileWriteback and callers.  It's
  silly to define these counts as narrower than they might someday
  need to be.  Also, I believe that the BLCKSZ * nflush calculation in
  mdwriteback was capable of overflowing an int.
  http://git.postgresql.org/pg/commitdiff/95ef43c4308102d23afa887c9fc28d9977612a2d

- Fix pg_dump so pg_upgrade'ing an extension with simple opfamilies
  works.  As reported by Michael Feld, pg_upgrade'ing an installation
  having extensions with operator families that contain just a single
  operator class failed to reproduce the extension membership of those
  operator families.  This caused no immediate ill effects, but would
  create problems when later trying to do a plain dump and restore,
  because the seemingly-not-part-of- the-extension operator families
  would appear separately in the pg_dump output, and then would
  conflict with the families created by loading the extension.  This
  has been broken ever since extensions were introduced, and many of
  the standard contrib extensions are affected, so it's a bit
  astonishing nobody complained before.  The cause of the problem is a
  perhaps-ill-considered decision to omit such operator families from
  pg_dump's output on the grounds that the CREATE OPERATOR CLASS
  commands could recreate them, and having explicit CREATE OPERATOR
  FAMILY commands would impede loading the dump script into pre-8.3
  servers.  Whatever the merits of that decision when 8.3 was being
  written, it looks like a poor tradeoff now.  We can fix the
  pg_upgrade problem simply by removing that code, so that the
  operator families are dumped explicitly (and then will be properly
  made to be part of their extensions).  Although this fixes the
  behavior of future pg_upgrade runs, it does nothing to clean up
  existing installations that may have improperly-linked operator
  families.  Given the small number of complaints to date, maybe we
  don't need to worry about providing an automated solution for that;
  anyone who needs to clean it up can do so with manual "ALTER
  EXTENSION ADD OPERATOR FAMILY" commands, or even just ignore the
  duplicate-opfamily errors they get during a pg_restore.  In any case
  we need this fix.  Back-patch to all supported branches.
  Discussion: <20228.1460575691@sss.pgh.pa.us>
  http://git.postgresql.org/pg/commitdiff/6cead413bb92be0579a2dbf6320121edcc32e369

- Fix broken dependency-mongering for index operator classes/families.
  For a long time, opclasscmds.c explained that "we do not create a
  dependency link to the AM [for an opclass or opfamily], because we
  don't currently support DROP ACCESS METHOD".  Commit
  473b93287040b200 invented DROP ACCESS METHOD, but it batted only 1
  for 2 on adding the dependency links, and 0 for 2 on updating the
  comments about the topic.  In passing, undo the same commit's
  entirely inappropriate decision to blow away an existing index as a
  side-effect of create_am.sql.
  http://git.postgresql.org/pg/commitdiff/92a30a7eb0cadb008e18053f199af7de3fc1abaa

- Fix prototype of pgwin32_bind().  I (tgl) had copied-and-pasted this
  from pgwin32_accept(), failing to notice that the third parameter
  should be "int" not "int *".  David Rowley
  http://git.postgresql.org/pg/commitdiff/22989a8e34168f576e0f90b16fc3edabd28c40e6

- Provide errno-translation wrappers around bind() and listen() on
  Windows.  I've seen one too many "could not bind IPv4 socket: No
  error" log entries from the Windows buildfarm members.  Per previous
  discussion, this is likely caused by the fact that we're doing
  nothing to translate WSAGetLastError() to errno.  Put in a wrapper
  layer to do that.  If this works as expected, it should get
  back-patched, but let's see what happens in the buildfarm first.
  Discussion: <4065.1452450340@sss.pgh.pa.us>
  http://git.postgresql.org/pg/commitdiff/d1b7d4877b9a71f476e8e5adea3b6afe419896ba

- Docs: clarify description of LIMIT/OFFSET behavior.  Section 7.6 was
  a tad confusing because it specified what LIMIT NULL does, but
  neglected to do the same for OFFSET NULL, making this look like
  perhaps a special case or a wrong restatement of the bit about LIMIT
  ALL.  Wordsmith a bit while at it.  Per bug #14084.
  http://git.postgresql.org/pg/commitdiff/fda21aa05bdc96c2c4141f5fd1245a11a41cf62c

- Adjust datatype of ReplicationState.acquired_by.  It was declared as
  "pid_t", which would be fine except that none of the places that
  printed it in error messages took any thought for the possibility
  that it's not equivalent to "int".  This leads to warnings on some
  buildfarm members, and could possibly lead to actually wrong error
  messages on those platforms.  There doesn't seem to be any very good
  reason not to just make it "int"; it's only ever assigned from
  MyProcPid, which is int.  If we want to cope with PIDs that are
  wider than int, this is not the place to start.  Also, fix the
  comment, which seems to perhaps be a leftover from a time when the
  field was only a bool?  Per buildfarm.  Back-patch to 9.5 which has
  same issue.
  http://git.postgresql.org/pg/commitdiff/994f11257328e272a6a43d3de59ffa916cbfbe96

- Adjust signature of walrcv_receive hook.  Commit 314cbfc5da988eff
  redefined the signature of this hook as typedef int
  (*walrcv_receive_type) (char **buffer, int *wait_fd); But in fact
  the type of the "wait_fd" variable ought to be pgsocket, which is
  what WaitLatchOrSocket expects, and which is necessary if we want to
  be able to assign PGINVALID_SOCKET to it on Windows.  So fix that.
  http://git.postgresql.org/pg/commitdiff/c2dc194bdbf5f84ceb433ed416eb389c1234ebc9

- Fix core dump in ReorderBufferRestoreChange on alignment-picky
  platforms.  When re-reading an update involving both an old tuple
  and a new tuple from disk, reorderbuffer.c was careless about
  whether the new tuple is suitably aligned for direct access --- in
  general, it isn't.  We'd missed seeing this in the buildfarm because
  the contrib/test_decoding tests exercise this code path only a few
  times, and by chance all of those cases have old tuples with length
  a multiple of 4, which is usually enough to make the access to the
  new tuple's t_len safe.  For some still-not-entirely-clear reason,
  however, Debian's sparc build gets a bus error, as reported by
  Christoph Berg; perhaps it's assuming 8-byte alignment of the
  pointer?  The lack of previous field reports is probably because you
  need all of these conditions to trigger a crash: an alignment-picky
  platform (not Intel), a transaction large enough to spill to disk,
  an update within that xact that changes a primary-key field and has
  an odd-length old tuple, and of course logical decoding tracing the
  transaction.  Avoid the alignment assumption by using memcpy instead
  of fetching t_len directly, and add a test case that exposes the
  crash on picky platforms.  Back-patch to 9.4 where the bug was
  introduced.  Discussion: <20160413094117.GC21485@msg.credativ.de>
  http://git.postgresql.org/pg/commitdiff/6a3d3965d6d5eec30e1c36b3ffa3355ee9201933

- Rethink \crosstabview's argument parsing logic.  \crosstabview
  interpreted its arguments in an unusual way, including doing
  case-insensitive matching of unquoted column names, which is surely
  not the right thing.  Rip that out in favor of doing something
  equivalent to the dequoting/case-folding rules used by other psql
  commands.  To keep it simple, change the syntax so that the optional
  sort column is specified as a separate argument, instead of the
  also-quite-unusual syntax that attached it to the colH argument with
  a colon.  Also, rework the error messages to be closer to project
  style.
  http://git.postgresql.org/pg/commitdiff/6f0d6a507889d94a79c0d18577a0cb1ccc2b6815

- Fix memory leak in GIN index scans.  The code had a query-lifespan
  memory leak when encountering GIN entries that have posting lists
  (rather than posting trees, ie, there are a relatively small number
  of heap tuples containing this index key value).  With a suitable
  data distribution this could add up to a lot of leakage.  Problem
  seems to have been introduced by commit 36a35c550, so back-patch to
  9.4.  Julien Rouhaud
  http://git.postgresql.org/pg/commitdiff/f0e766bd7f77774075297526bd2da8f3de226c1f

- Fix portability problem induced by commit a6f6b7819.  pg_xlogdump
  includes bufmgr.h.  With a compiler that emits code for static
  inline functions even when they're unreferenced, that leads to
  unresolved external references in the new static-inline version of
  BufferGetPage().  So hide it with #ifndef FRONTEND, as we've done
  for similar issues elsewhere.  Per buildfarm member pademelon.
  http://git.postgresql.org/pg/commitdiff/6b85d4ba9b09dc94cf1b14aef517da095a83cdbb

- Fix possible crash in ALTER TABLE ... REPLICA IDENTITY USING INDEX.
  Careless coding added by commit 07cacba983ef79be could result in a
  crash or a bizarre error message if someone tried to select an index
  on the OID column as the replica identity index for a table.
  Back-patch to 9.4 where the feature was introduced.  Discussion:
  CAKJS1f8TQYgTRDyF1_u9PVCKWRWz+DkieH=U7954HeHVPJKaKg@mail.gmail.com
  David Rowley
  http://git.postgresql.org/pg/commitdiff/8f1911d5e6d5a1e62c860ddb040d664b01c6415c

- Use less-generic names in matview.sql.  The original coding of this
  test used table and view names like "t", "tv", "foo", etc.  This
  tended to interfere with doing simple manual tests in the regression
  database; not to mention that it posed a considerable risk of
  conflict with other regression test scripts.  Prefix these names
  with "mvtest_" to avoid such conflicts.  Also, change
  transiently-created role name to be "regress_xxx" per discussions
  about being careful with regression-test role creation.
  http://git.postgresql.org/pg/commitdiff/4447f0bcb66547708fa977d6b252046e792a7e04

- Disallow creation of indexes on system columns (except for OID).
  Although OID acts pretty much like user data, the other system
  columns do not, so an index on one would likely misbehave.  And it's
  pretty hard to see a use-case for one, anyway.  Let's just forbid
  the case rather than worry about whether it should be supported.
  David Rowley
  http://git.postgresql.org/pg/commitdiff/c34df8a003c3e478d70e8251bd2a24d710b297d4

- Adjust spin.c's spinlock emulation so that 0 is not a valid spinlock
  value.  We've had repeated troubles over the years with failures to
  initialize spinlocks correctly; see 6b93fcd14 for a recent example.
  Most of the time, on most platforms, such oversights can escape
  notice because all-zeroes is the expected initial content of an
  slock_t variable.  The only platform we have where the initialized
  state of an slock_t isn't zeroes is HPPA, and that's practically
  gone in the wild.  To make it easier to catch such errors without
  needing one of those, adjust the --disable-spinlocks code so that
  zero is not a valid value for an slock_t for it.  In passing, remove
  a bunch of unnecessary #include's from spin.c; commit
  daa7527afc227443 removed all the intermodule coupling that made them
  necessary.
  http://git.postgresql.org/pg/commitdiff/4039c736eb0955cb1daf88e211f105dbbb78f7ea

- Avoid code duplication in \crosstabview.  In commit 6f0d6a507 I
  added a duplicate copy of psqlscanslash's identifier downcasing
  code, but actually it's not hard to split that out as a callable
  subroutine and avoid the duplication.
  http://git.postgresql.org/pg/commitdiff/9603a32594d2f5e6d9a1f098bc554a68f44ccb3c

Stephen Frost pushed:

- Correct copyright for newly added genericdesc.c It's 2016 these days
  (no, not entirely sure how we got here either).  Pointed out by Amit
  Langote
  http://git.postgresql.org/pg/commitdiff/cd13471f2e9dee6d411cae3ddae72d0ad6b58c4d

- Disallow SET SESSION AUTHORIZATION pg_* As part of reserving the
  pg_* namespace for default roles and in line with SET ROLE and other
  previous efforts, disallow settings the role to a default/reserved
  role using SET SESSION AUTHORIZATION.  These checks and restrictions
  on what is allowed regarding default / reserved roles are under
  debate, but it seems prudent to ensure that the existing checks at
  least cover the intended cases while the debate rages on.  On me to
  clean it up if the consensus decision is to remove these checks.
  http://git.postgresql.org/pg/commitdiff/bfed4ab824789fd7c000286650d4498dccb05634

- In recordExtensionInitPriv(), keep the scan til we're done with it
  For reasons of sheer brain fade, we (I) was calling
  systable_endscan() immediately after systable_getnext() and
  expecting the tuple returned by systable_getnext() to still be
  valid.  That's clearly wrong.  Move the systable_endscan() down
  below the tuple usage.  Discovered initially by Pavel Stehule and
  then also by Alvaro.  Add a regression test based on Alvaro's
  testing.
  http://git.postgresql.org/pg/commitdiff/99f2f3c19ae7d6aa2950a9bdb549217c5a60d941

Kevin Grittner pushed:

- Make oldSnapshotControl a pointer to a volatile structure It was
  incorrectly declared as a volatile pointer to a non-volatile
  structure.  Eliminate the OldSnapshotControl struct definition; it
  is really not needed.  Pointed out by Tom Lane.  While at it, add
  OldSnapshotControlData to pgindent's list of structures.
  http://git.postgresql.org/pg/commitdiff/80647bf65a03e232c995c0826ef394dad8d685fe

- Use static inline function for BufferGetPage() I was initially
  concerned that the some of the hundreds of references to
  BufferGetPage() where the literal BGP_NO_SNAPSHOT_TEST were passed
  might not optimize as well as a macro, leading to some hard-to-find
  performance regressions in corner cases.  Inspection of disassembled
  code has shown identical code at all inspected locations, and the
  size difference doesn't amount to even one byte per such call.  So
  make it readable.  Per gripes from Álvaro Herrera and Tom Lane
  http://git.postgresql.org/pg/commitdiff/a6f6b78196a701702ec4ff6df56c346bdcf9abd2

- Avoid extra locks in GetSnapshotData if old_snapshot_threshold < 0
  On a big NUMA machine with 1000 connections in saturation load there
  was a performance regression due to spinlock contention, for
  acquiring values which were never used.  Just fill with dummy values
  if we're not going to use them.  This patch has not been benchmarked
  yet on a big NUMA machine, but it seems like a good idea on general
  principle, and it seemed to prevent an apparent 2.2% regression on a
  single-socket i7 box running 200 connections at saturation load.
  http://git.postgresql.org/pg/commitdiff/2201d801b03c2d1b0bce4d6580b718dc34d38b3e

Teodor Sigaev pushed:

- Add page id to bloom index Added to ensure that bloom index pages
  can be distinguished from other pages by pg_filedump. Because there
  wasn't any public/production versions before, it doesn't pay
  attention to any compatibility issues.  Per notice from Tom Lane
  http://git.postgresql.org/pg/commitdiff/813b456ea21d4cf57b124bf855ec019c7a8099a7

Robert Haas pushed:

- Fix costing for parallel aggregation.  The original patch kind of
  ignored the fact that we were doing something different from a
  costing point of view, but nobody noticed.  This patch fixes that
  oversight.  David Rowley
  http://git.postgresql.org/pg/commitdiff/deb71fa9713dfe374a74fc58a5d298b5f25da3f5

- Use PG_INT32_MIN instead of reiterating the constant.  Makes no
  difference, but it's cleaner this way.  Michael Paquier
  http://git.postgresql.org/pg/commitdiff/cbb2a812d710dd58e68088b334f8c492346a0d0f

- Tweak EXPLAIN for parallel query to show workers launched.  The
  previous display was sort of confusing, because it didn't
  distinguish between the number of workers that we planned to launch
  and the number that actually got launched.  This has already
  confused several people, so display both numbers and label them
  clearly.  Julien Rouhaud, reviewed by me.
  http://git.postgresql.org/pg/commitdiff/5702277ca97396384eaf5c58d582b79b9984ce73

- postgres_fdw: Clean up handling of system columns.  Previously,
  querying the xmin column of a single postgres_fdw foreign table
  fetched the tuple length, xmax the typmod, and cmin or cmax the
  composite type OID of the tuple.  However, when you queried several
  such tables and the join got shipped to the remote side, these
  columns ended up containing the remote values of the corresponding
  columns.  Both behaviors are rather unprincipled, the former for
  obvious reasons and the latter because the remote values of these
  columns don't have any local significance; our transaction IDs are
  in a different space than those of the remote machine.  Clean this
  up by setting all of these fields to 0 in both cases.  Also fix the
  handling of tableoid to be sane.  Robert Haas and Ashutosh Bapat,
  reviewed by Etsuro Fujita.
  http://git.postgresql.org/pg/commitdiff/da7d44b627ba839de32c9409aca659f60324de76

Andres Freund pushed:

- void atomic operation in MarkLocalBufferDirty().  The recent patch
  to make Pin/UnpinBuffer lockfree in the hot path (48354581a),
  accidentally used pg_atomic_fetch_or_u32() in
  MarkLocalBufferDirty(). Other code operating on local buffers was
  careful to only use pg_atomic_read/write_u32 which just read/write
  from memory; to avoid unnecessary overhead.  On its own that'd just
  make MarkLocalBufferDirty() slightly less efficient, but in addition
  InitLocalBuffers() doesn't call pg_atomic_init_u32() - thus the
  spinlock fallback for the atomic operations isn't initialized. That
  in turn caused, as reported by Tom, buildfarm animal gaur to fail.
  As those errors are actually useful against this type of error,
  continue to omit - intentionally this time - initialization of the
  atomic variable.  In addition, add an explicit note about only using
  pg_atomic_read/write on local buffers's state to BufferDesc's
  description.  Reported-By: Tom Lane Discussion:
  1881.1460431476@sss.pgh.pa.us
  http://git.postgresql.org/pg/commitdiff/6b93fcd149329d4ee7319561b30fc15a573c6307

- Make init_spin_delay() C89 compliant and change stuck spinlock
  reporting.  The current definition of init_spin_delay (introduced
  recently in 48354581a) wasn't C89 compliant. It's not legal to refer
  to refer to non-constant expressions, and the ptr argument was one.
  This, as reported by Tom, lead to a failure on buildfarm animal
  pademelon.  The pointer, especially on system systems with ASLR,
  isn't super helpful anyway, though. So instead of making
  init_spin_delay into an inline function, make s_lock_stuck() report
  the function name in addition to file:line and change
  init_spin_delay() accordingly. While not a direct replacement, the
  function name is likely more useful anyway (line numbers are often
  hard to interpret in third party reports).  This also fixes what
  file/line number is reported for waits via s_lock().  As
  PG_FUNCNAME_MACRO is now used outside of elog.h, move it to c.h.
  Reported-By: Tom Lane Discussion: 4369.1460435533@sss.pgh.pa.us
  http://git.postgresql.org/pg/commitdiff/80abbeba23d466b6541cf95082a9e1f36704424e

- Add required database and origin filtering for logical messages.
  Logical messages, added in 3fe3511d05, during decoding failed to
  filter messages emitted in other databases and messages emitted
  "under" a replication origin the output plugin isn't interested in.
  Add tests to verify that both types of filtering actually work.
  While touching message.sql remove hunk obsoleted by d25379e.  Bump
  XLOG_PAGE_MAGIC because xl_logical_message changed and because
  3fe3511d05 had omitted doing so. 3fe3511d05 additionally didn't bump
  catversion, but 7a542700d has done so since.  Author: Petr Jelinek
  Reported-By: Andres Freund Discussion:
  20160406142513.wotqy3ba3kanr423@alap3.anarazel.de
  http://git.postgresql.org/pg/commitdiff/be65eddd80093a923b091dc60776aa6f966d1f07

- Remove trailing commas in enums.  These aren't valid C89. Found
  thanks to gcc's -Wc90-c99-compat. These exist in differing places in
  most supported branches.
  http://git.postgresql.org/pg/commitdiff/533cd2303aa6558721e76295fd1ffb05211764f9

- Make init_spin_delay() C89 compliant #2.  My previous attempt at
  doing so, in 80abbeba23, was not sufficient. While that fixed the
  problem for bufmgr.c and lwlock.c , s_lock.c still has non-constant
  expressions in the struct initializer, because the
  file/line/function information comes from the caller of s_lock().
  Give up on using a macro, and use a static inline instead.
  Discussion: 4369.1460435533@sss.pgh.pa.us
  http://git.postgresql.org/pg/commitdiff/4b74c6a40e7ac9dad7cdeb4cfd2d51ea60cfdbb5

- Fix trivial typo.
  http://git.postgresql.org/pg/commitdiff/7b16781228d6c0a2db66d71e33e64b9606779feb

Magnus Hagander pushed:

- Update helptext for vcregress.pl.  This has clearly not been
  tracking the code changse for quite some time.  Michael Paquier,
  problem spotted by Kyotaro HORIGUCHI
  http://git.postgresql.org/pg/commitdiff/cf086b1c2fa1e11c14a9fe5fea05553974a480ef

- Fix typo in comment
  http://git.postgresql.org/pg/commitdiff/ba8fe38f58e2f3d86c5361373598af80d5ce4443

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Michaël Paquier sent in two more revisions of a patch to add VS 2015
support to MSVC.

Robert Haas sent in a patch to fix some alignment issues in
src/backend/storage/buffer/buf_init.c.

Stas Kelvich and Michaël Paquier traded patches to speed up two-phase
commits.

Etsuro Fujita sent in a patch to improve the way foreign tables get
written to in the PostgreSQL FDW.

Anastasia Lubennikova sent in another revision of a patch to implement
covering unique indexes.

Amit Kapila sent in a patch to pad the PGXACT struct out to 64 bytes.

Teodor Sigaev sent in a patch to fix some GIN index corruption bugs.

David Rowley sent in two revisions of a patch to fix some issues with
EXPLAIN output for parallel aggregates.

Ashutosh Sharma fix an issue with pg_basebackup's handling of
symlinks.

Peter Geoghegan sent in a patch to remove an obsolete comment from
fmgr.c.

Amit Langote sent in another revision of a patch to implement
declarative partitioning.

Michaël Paquier sent in three more revisions of a patch to fix
interrupt handling in the PostgreSQL FDW.

David Rowley sent in three revisions of a patch to disallow creating
unique indexes on system columns where that doesn't make sense.

Etsuro Fujita sent in a patch to fix an issue where a combination of
FULL and INNER joins could produce a wrong result with the PostgreSQL
FDW.

Feike Steenbergen sent in a patch to make pg_get_functiondef actually
add parallel indicators.

Piotr Stefaniak sent in another revision of a patch to avoid passing
null pointers to functions that require the pointers to be non null.

Magnus Hagander sent in a patch to fix some issues with the backup
docs.

Craig Ringer sent in a patch to enable logical timeline following in
the walsender.

Terence Ferraro sent in a patch to make it possible for an environment
variable to be provided to libpq to specify where to find the SSL
certificate/key files used for a secure connection.