== PostgreSQL Weekly News - July 02 2012 ==

== PostgreSQL Weekly News - July 02 2012 ==

Kevin Grittner and Dan Ports will be presenting their paper on SSI at
VLDB in Istanbul.  While they won't be the first or only people there
to do their work based on PostgreSQL, they will be the first public
representatives of the PostgreSQL community to do so.
http://sacan.biomed.drexel.edu/vldb2012/program.php#Industrial_Session_Abstracts
http://drkp.net/drkp/papers/ssi-vldb12.pdf

PostgreSQL Conference Europe 2012 in Prague, The Czech Republic,
on October 23-26 is now accepting registrations for conference
attendance at
http://2012.pgconf.eu/registration/

== PostgreSQL Product News ==

AnySQL Maestro 12.6, an ODBC-based management tool which works with
PostgreSQL, released.
http://www.sqlmaestro.com/products/postgresql/datawizard/

pg_extractor 1.2.0, a customizing add-on to pg_dump, released.
https://github.com/omniti-labs/pg_extractor

== PostgreSQL Jobs for July ==

http://archives.postgresql.org/pgsql-jobs/2012-07/threads.php

== PostgreSQL Local ==

Everything this week was global.

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

Kevin Grittner pushed:

- Fix warning for 64-bit literal on 32-bit build.
  http://git.postgresql.org/pg/commitdiff/5c7f954d310783d49724367c9fa6514bc62b7cce

Robert Haas pushed:

- Remove sanity test in XRecOffIsValid.  Commit
  061e7efb1b4c5b8a5d02122b7780531b8d5bf23d changed the rules for
  splitting xlog records across pages, but neglected to update this
  test.  It's possible that there's some better action here than just
  removing the test completely, but this at least appears to get some
  of the things that are currently broken (like initdb on MacOS X)
  working again.
  http://git.postgresql.org/pg/commitdiff/2dfa87bcb6eb3ee6e41c40ed4a8a43019a66bd38

- Fix typo in DEBUG message, introduced by recent WAL refactoring.
  Fujii Masao
  http://git.postgresql.org/pg/commitdiff/c7d47abd04dc1322fd545370cfeb743680df0e3a

- Unbreak pg_resetxlog -l.  Fujii Masao
  http://git.postgresql.org/pg/commitdiff/a6427f1f478b0bf43d1b861ee4053e2e8bc6118b

- Backport fsync queue compaction logic to all supported branches.
  This backports commit 7f242d880b5b5d9642675517466d31373961cf98,
  except for the counter in pg_stat_bgwriter.  The underlying problem
  (namely, that a full fsync request queue causes terrible checkpoint
  behavior) continues to be reported in the wild, and this code seems
  to be safe and robust enough to risk back-porting the fix.
  http://git.postgresql.org/pg/commitdiff/73a3b1d4589eaf3dc7f0a573727a2a6ac5279e6a

- Reduce use of heavyweight locking inside hash AM.  Avoid using
  LockPage(rel, 0, lockmode) to protect against changes to the bucket
  mapping.  Instead, an exclusive buffer content lock is now viewed as
  sufficient permission to modify the metapage, and a shared buffer
  content lock is used when such modifications need to be prevented.
  This more relaxed locking regimen makes it possible that, when we're
  busy getting a heavyweight bucket on the bucket we intend to search
  or insert into, a bucket split might occur underneath us.  To
  compenate for that possibility, we use a loop-and-retry system:
  release the metapage content lock, acquire the heavyweight lock on
  the target bucket, and then reacquire the metapage content lock and
  check that the bucket mapping has not changed.   Normally it hasn't,
  and we're done.  But if by chance it has, we simply unlock the
  metapage, release the heavyweight lock we acquired previously, lock
  the new bucket, and loop around again.  Even in the worst case we
  cannot loop very many times here, since we don't split the same
  bucket again until we've split all the other buckets, and 2^N gets
  big pretty fast.  This results in greatly improved concurrency,
  because we're effectively replacing two lwlock acquire-and-release
  cycles in exclusive mode (on one of the lock manager locks) with a
  single acquire-and-release cycle in shared mode (on the metapage
  buffer content lock).  Testing shows that it's still not quite as
  good as btree; for that, we'd probably have to find some way of
  getting rid of the heavyweight bucket locks as well, which does not
  appear straightforward.  Patch by me, review by Jeff Janes.
  http://git.postgresql.org/pg/commitdiff/76837c1507cb5a5a0048046233568447729e66dd

- Make DROP FUNCTION hint more informative.  If you decide you want to
  take the hint, this gives you something you can paste right back to
  the server.  Dean Rasheed
  http://git.postgresql.org/pg/commitdiff/0caa0d04db24d2c571fa7daa410bc6a5b319a2a2

- When LWLOCK_STATS is defined, count spindelays.  When LWLOCK_STATS
  is *not* defined, the only change is that SpinLockAcquire now
  returns the number of delays.  Patch by me, review by Jeff Janes.
  http://git.postgresql.org/pg/commitdiff/b79ab00144e64217d418fde884bca8ea58fbd4a4

- Allow pg_terminate_backend() to be used on backends with matching
  role.  A similar change was made previously for pg_cancel_backend,
  so now it all matches again.  Dan Farina, reviewed by Fujii Masao,
  Noah Misch, and Jeff Davis, with slight kibitzing on the doc changes
  by me.
  http://git.postgresql.org/pg/commitdiff/c60ca19de9ad777c51243605571d1d7606000f08

- Update release notes for pg_terminate_backend changes.
  http://git.postgresql.org/pg/commitdiff/7700b82e6b071f298e3426042197c13843a5b499

- Add missing space in event_source GUC description.  This has
  apparently been wrong since event_source was added.  Alexander
  Lakhin
  http://git.postgresql.org/pg/commitdiff/c5b3451a8e72cb7825933d4f4827f467cb38b498

- Dramatically reduce System V shared memory consumption.  Except when
  compiling with EXEC_BACKEND, we'll now allocate only a tiny amount
  of System V shared memory (as an interlock to protect the data
  directory) and allocate the rest as anonymous shared memory via
  mmap.  This will hopefully spare most users the hassle of adjusting
  operating system parameters before being able to start PostgreSQL
  with a reasonable value for shared_buffers.  There are a bunch of
  documentation updates needed here, and we might need to adjust some
  of the HINT messages related to shared memory as well.  But it's not
  100% clear how portable this is, so before we write the
  documentation, let's give it a spin on the buildfarm and see what
  turns red.
  http://git.postgresql.org/pg/commitdiff/b0fc0df9364d2d2d17c0162cf3b8b59f6cb09f67

- Fix broken mmap failure-detection code, and improve error message.
  Per an observation by Thom Brown that my previous commit made an
  overly large shmem allocation crash the server, on Linux.
  http://git.postgresql.org/pg/commitdiff/39715af23ae459684963c350dd69eafa2d502e7e

- Make walsender more responsive.  Per testing by Andres Freund, this
  improves replication performance and reduces replication latency and
  latency jitter.  I was a bit concerned about moving more work into
  XLogInsert, but testing seems to show that it's not a problem in
  practice.  Along the way, improve comments for WaitLatchOrSocket.
  Andres Freund.  Review and stylistic cleanup by me.
  http://git.postgresql.org/pg/commitdiff/f83b59997d29f06c3d67e7eb9a1f2c9cd017d665

- Make commit_delay much smarter.  Instead of letting every backend
  participating in a group commit wait independently, have the first
  one that becomes ready to flush WAL wait for the configured delay,
  and let all the others wait just long enough for that first process
  to complete its flush.  This greatly increases the chances of being
  able to configure a commit_delay setting that actually improves
  performance.  As a side consequence of this change, commit_delay now
  affects all WAL flushes, rather than just commits.  There was some
  discussion on pgsql-hackers about whether to rename the GUC to, say,
  wal_flush_delay, but in the absence of consensus I am leaving it
  alone for now.  Peter Geoghegan, with some changes, mostly to the
  documentation, by me.
  http://git.postgresql.org/pg/commitdiff/f11e8be3e812cdbbc139c1b4e49141378b118dee

- Work a little harder on comments for walsender wakeup patch.  Per
  gripe from Tom Lane.
  http://git.postgresql.org/pg/commitdiff/82cdd2df759efe2b43183ee954b4a2e10b2c59f4

- Fix position of WalSndWakeupRequest call.  This avoids
  discriminating against wal_sync_method = open_sync or open_datasync.
  Fujii Masao, reviewed by Andres Freund
  http://git.postgresql.org/pg/commitdiff/3bb592bb20d02093d6488a57c7c4ee94803ddc9a

- Fix a stupid bug I introduced into XLogFlush().  Commit
  f11e8be3e812cdbbc139c1b4e49141378b118dee broke this; it was right in
  Peter's original patch, but I messed it up before committing.
  http://git.postgresql.org/pg/commitdiff/3cf39e6ddbece4000ee56a0f79cdbe71fb2865ff

Peter Eisentraut pushed:

- Unify calling conventions for postgres/postmaster sub-main
  functions.  There was a wild mix of calling conventions: Some were
  declared to return void and didn't return, some returned an int exit
  code, some claimed to return an exit code, which the callers
  checked, but actually never returned, and so on.  Now all of these
  functions are declared to return void and decorated with attribute
  noreturn and don't return.  That's easiest, and most code already
  worked that way.
  http://git.postgresql.org/pg/commitdiff/eeece9e60984e76e5a41c1e2fa9efc5a1761e560

- Use system install program when available and usable.  In
  a3176dac22c4cd14971e35119e245abee7649cb9 we switched to using
  install-sh unconditionally, because the configure check
  AC_PROG_INSTALL would pick up any random program named install,
  which has caused failure reports
  (http://archives.postgresql.org/pgsql-hackers/2001-03/msg00312.php).
  Now the configure check is much improved and should avoid false
  positives.  It has also been shown that using a system install
  program can significantly reduce "make install" times, so it's worth
  trying.
  http://git.postgresql.org/pg/commitdiff/9db7ccae2000524b72a4052352cbb5407fb53b02

- Fix install program detection.  configure handles INSTALL as a
  substitution variable specially, and apparently it gets confused
  when it's set to empty.  Use INSTALL_ instead as a workaround to
  avoid the issue.
  http://git.postgresql.org/pg/commitdiff/f7867154129781ee1522344bef50890c01f2b47a

- Further fix install program detection.  The $(or) make function was
  introduced in GNU make 3.81, so the previous coding didn't work in
  3.80.  Write it differently, and improve the variable naming to make
  more sense in the new coding.
  http://git.postgresql.org/pg/commitdiff/dcd5af6c3498a265053aa3292d41c3946e225627

- Make init-po and update-po recursive make targets.  This is for
  convenience, now that adding recursive targets is much easier than
  it used to be when the NLS stuff was initially added.
  http://git.postgresql.org/pg/commitdiff/b344c651fb87cb7c7f9f59b714e2879e777caf66

- initdb: Update check_need_password for new options.  Change things
  so that something like initdb --auth-local=peer --auth-host=md5 does
  not cause a "must specify a password" error, like initdb -A md5
  does.
  http://git.postgresql.org/pg/commitdiff/e4ffa86b5739fdf85b1050c4b2e26ab14ef476e9

- Assorted message style improvements
  http://git.postgresql.org/pg/commitdiff/2b44306315cf84479f735b12f78499616172dbb9

Alvaro Herrera pushed:

- Tighten up includes in sinvaladt.h, twophase.h, proc.h.  Remove
  proc.h from sinvaladt.h and twophase.h; also replace xlog.h in
  proc.h with xlogdefs.h.
  http://git.postgresql.org/pg/commitdiff/77ed0c69504aad141dea314b1de261195aae5c9e

- pg_upgrade: fix off-by-one mistake in snprintf.  snprintf counts
  trailing NUL towards the char limit.  Failing to account for that
  was causing an invalid value to be passed to pg_resetxlog -l,
  aborting the upgrade process.
  http://git.postgresql.org/pg/commitdiff/9e26326ad6cd11ac32d11e6cbeb613443f361da6

- Make the pg_upgrade log files contain actual commands.  Now the log
  file not only contains the output from commands executed by
  system(), but also what command it was in the first place.  This
  arrangement makes debugging a lot simpler.
  http://git.postgresql.org/pg/commitdiff/4741e9afb93f0d769655b2d18c2b73b86f281010

Tom Lane pushed:

- Make pg_dump emit more accurate dependency information.  While
  pg_dump has included dependency information in archive-format output
  ever since 7.3, it never made any large effort to ensure that that
  information was actually useful.  In particular, in common
  situations where dependency chains include objects that aren't
  separately emitted in the dump, the dependencies shown for objects
  that were emitted would reference the dump IDs of these un-dumped
  objects, leaving no clue about which other objects the visible
  objects indirectly depend on.  So far, parallel pg_restore has
  managed to avoid tripping over this misfeature, but only by dint of
  some crude hacks like not trusting dependency information in the
  pre-data section of the archive.  It seems prudent to do something
  about this before it rises up to bite us, so instead of emitting the
  "raw" dependencies of each dumped object, recursively search for its
  actual dependencies among the subset of objects that are being
  dumped.  Back-patch to 9.2, since that code hasn't yet diverged
  materially from HEAD.  At some point we might need to back-patch
  further, but right now there are no known cases where this is
  actively necessary.  (The one known case, bug #6699, is fixed in a
  different way by my previous patch.) Since this patch depends on 9.2
  changes that made TOC entries be marked before output commences as
  to whether they'll be dumped, back-patching further would require
  additional surgery; and as of now there's no evidence that it's
  worth the risk.
  http://git.postgresql.org/pg/commitdiff/8a504a363925fc5c7af48cd723da3f7e4d7ba9e2

- Improve pg_dump's dependency-sorting logic to enforce section dump
  order.  As of 9.2, with the --section option, it is very important
  that the concept of "pre data", "data", and "post data" sections of
  the output be honored strictly; else a dump divided into separate
  sectional files might be unrestorable.  However, the
  dependency-sorting logic knew nothing of sections and would happily
  select output orderings that didn't fit that structure.  Doing so
  was mostly harmless before 9.2, but now we need to be sure it
  doesn't do that.  To fix, create dummy objects representing the
  section boundaries and add dependencies between them and all the
  normal objects.  (This might sound expensive but it seems to only
  add a percent or two to pg_dump's runtime.) This also fixes a
  problem introduced in 9.1 by the feature that allows incomplete
  GROUP BY lists when a primary key is given in GROUP BY.  That means
  that views can depend on primary key constraints.  Previously,
  pg_dump would deal with that by simply emitting the primary key
  constraint before the view definition (and hence before the data
  section of the output).  That's bad enough for simple serial
  restores, where creating an index before the data is loaded works,
  but is undesirable for speed reasons.  But it could lead to outright
  failure of parallel restores, as seen in bug #6699 from Joe Van Dyk.
  That happened because pg_restore would switch into parallel mode as
  soon as it reached the constraint, and then very possibly would try
  to emit the view definition before the primary key was committed (as
  a consequence of another bug that causes the view not to be
  correctly marked as depending on the constraint).  Adding the
  section boundary constraints forces the dependency-sorting code to
  break the view into separate table and rule declarations, allowing
  the rule, and hence the primary key constraint it depends on, to
  revert to their intended location in the post-data section.  This
  also somewhat accidentally works around the bogus-dependency-marking
  problem, because the rule will be correctly shown as depending on
  the constraint, so parallel pg_restore will now do the right thing.
  (We will fix the bogus-dependency problem for real in a separate
  patch, but that patch is not easily back-portable to 9.1, so the
  fact that this patch is enough to dodge the only known symptom is
  fortunate.) Back-patch to 9.1, except for the hunk that adds
  verification that the finished archive TOC list is in correct
  section order; the place where it was convenient to add that doesn't
  exist in 9.1.
  http://git.postgresql.org/pg/commitdiff/a1ef01fe163b304760088e3e30eb22036910a495

- Cope with smaller-than-normal BLCKSZ setting in SPGiST indexes on
  text.  The original coding failed miserably for BLCKSZ of 4K or
  less, as reported by Josh Kupershmidt.  With the present design for
  text indexes, a given inner tuple could have up to 256 labels
  (requiring either 3K or 4K bytes depending on MAXALIGN), which means
  that we can't positively guarantee no failures for smaller
  blocksizes.  But we can at least make it behave sanely so long as
  there are few enough labels to fit on a page.  Considering that
  btree is also more prone to "index tuple too large" failures when
  BLCKSZ is small, it's not clear that we should expend more work than
  this on this case.
  http://git.postgresql.org/pg/commitdiff/757773602c424b1e51c2d9cad8a59398ba7f7b2c

- Make UtilityContainsQuery recurse until it finds a non-utility
  Query.  The callers of UtilityContainsQuery want it to return a
  non-utility Query if it returns anything at all.  However, since we
  made CREATE TABLE Alexander Shulgin/SELECT INTO into a utility
  command instead of a variant of SELECT, a command like "EXPLAIN
  SELECT INTO" results in two nested utility statements.  So what we
  need UtilityContainsQuery to do is drill down to the bottom
  non-utility Query.  I had thought of this possibility in setrefs.c,
  and fixed it there by looping around the UtilityContainsQuery call;
  but overlooked that the call sites in plancache.c have a similar
  issue.  In those cases it's notationally inconvenient to provide an
  external loop, so let's redefine UtilityContainsQuery as recursing
  down to a non-utility Query instead.  Noted by Rushabh Lathia.  This
  is a somewhat cleaned-up version of his proposed patch.
  http://git.postgresql.org/pg/commitdiff/bde689f809027422d4c0baaa3e63b69ce5762e2c

- Provide MAP_FAILED if sys/mman.h doesn't.  On old HPUX this has to
  be #defined to -1.  It might be that other values are required on
  other dinosaur systems, but we'll worry about that when and if we
  get reports.
  http://git.postgresql.org/pg/commitdiff/c1494b733015bf09d75c362925ec3f2740a77f73

- Fix NOTIFY to cope with I/O problems, such as out-of-disk-space.
  The LISTEN/NOTIFY subsystem got confused if SimpleLruZeroPage
  failed, which would typically happen as a result of a write()
  failure while attempting to dump a dirty pg_notify page out of
  memory.  Subsequently, all attempts to send more NOTIFY messages
  would fail with messages like "Could not read from file
  "pg_notify/nnnn" at offset nnnnn: Success".  Only restarting the
  server would clear this condition.  Per reports from Kevin Grittner
  and Christoph Berg.  Back-patch to 9.0, where the problem was
  introduced during the LISTEN/NOTIFY rewrite.
  http://git.postgresql.org/pg/commitdiff/ae90128dc5f8412c8ce31804bbf0a0f8ab345db1

- Fix confusion between "size" and "AnonymousShmemSize".  Noted by
  Andres Freund.  Also improve a couple of comments.
  http://git.postgresql.org/pg/commitdiff/42e2ce6ae3e931953135a55b173a5ec4c54506c4

- Prevent CREATE TABLE LIKE/INHERITS from (mis) copying whole-row
  Vars.  If a CHECK constraint or index definition contained a
  whole-row Var (that is, "table.*"), an attempt to copy that
  definition via CREATE TABLE LIKE or table inheritance produced
  incorrect results: the copied Var still claimed to have the rowtype
  of the source table, rather than the created table.  For the LIKE
  case, it seems reasonable to just throw error for this situation,
  since the point of LIKE is that the new table is not permanently
  coupled to the old, so there's no reason to assume its rowtype will
  stay compatible.  In the inheritance case, we should ideally allow
  such constraints, but doing so will require nontrivial refactoring
  of CREATE TABLE processing (because we'd need to know the OID of the
  new table's rowtype before we adjust inherited CHECK constraints).
  In view of the lack of previous complaints, that doesn't seem worth
  the risk in a back-patched bug fix, so just make it throw error for
  the inheritance case as well.  Along the way, replace
  change_varattnos_of_a_node() with a more robust function
  map_variable_attnos(), which is capable of being extended to handle
  insertion of ConvertRowtypeExpr whenever we get around to fixing the
  inheritance case nicely, and in the meantime it returns a failure
  indication to the caller so that a helpful message with some context
  can be thrown.  Also, this code will do the right thing with
  subselects (if we ever allow them in CHECK or indexes), and it
  range-checks varattnos before using them to index into the map
  array.  Per report from Sergey Konoplev.  Back-patch to all
  supported branches.
  http://git.postgresql.org/pg/commitdiff/541ffa65c32b278da8ab2d19433fa6d37bd15c8d

- Declare AnonymousShmem pointer as "void *".  The original coding had
  it as "PGShmemHeader *", but that doesn't offer any notational
  benefit because we don't dereference it.  And it was resulting in
  compiler warnings on some platforms, notably buildfarm member
  castoroides, where mmap() and munmap() are evidently declared to
  take and return "char *".
  http://git.postgresql.org/pg/commitdiff/81e82643837de93909e0c5a8e14e805f3f69f41e

- Remove inappropriate semicolons after function definitions.  Solaris
  Studio warns about this, and some compilers might think it's an
  outright syntax error.
  http://git.postgresql.org/pg/commitdiff/fa188b5ef568446fe06fa6268c5592b12119c834

- Suppress compiler warnings in readfuncs.c.  Commit
  7357558fc8866e3a449aa9473c419b593d67b5b6 introduced "(void) token;"
  into the READ_TEMP_LOCALS() macro, to suppress complaints from gcc
  4.6 when the value of token was not used anywhere in a particular
  node-read function.  However, this just moved the warning around:
  inspection of buildfarm results shows that some compilers are now
  complaining that token is being read before it's set.  Revert the
  READ_TEMP_LOCALS() macro change and instead put "(void) token;" into
  READ_NODE_FIELD(), which is the principal culprit for cases where
  the warning might occur.  In principle we might need the same in
  READ_BITMAPSET_FIELD() and/or READ_LOCATION_FIELD(), but it seems
  unlikely that a node would consist only of such fields, so I'll
  leave them alone for now.
  http://git.postgresql.org/pg/commitdiff/39bfc94c86f1990e9db8ea3da0e82995cc1b76db

- Fix race condition in enum value comparisons.  When (re) loading the
  typcache comparison cache for an enum type's values, use an
  up-to-date MVCC snapshot, not the transaction's existing snapshot.
  This avoids problems if we encounter an enum OID that was created
  since our transaction started.  Per report from Andres Freund and
  diagnosis by Robert Haas.  To ensure this is safe even if enum
  comparison manages to get invoked before we've set a transaction
  snapshot, tweak GetLatestSnapshot to redirect to
  GetTransactionSnapshot instead of throwing error when
  FirstSnapshotSet is false.  The existing uses of GetLatestSnapshot
  (in ri_triggers.c) don't care since they couldn't be invoked except
  in a transaction that's already done some work --- but it seems just
  conceivable that this might not be true of enums, especially if we
  ever choose to use enums in system catalogs.  Note that the
  comparable coding in enum_endpoint and enum_range_internal remains
  GetTransactionSnapshot; this is perhaps debatable, but if we changed
  it those functions would have to be marked volatile, which doesn't
  seem attractive.  Back-patch to 9.1 where ALTER TYPE ADD VALUE was
  added.
  http://git.postgresql.org/pg/commitdiff/9ad45c18b6c8d03ce18a26223eb0d15e900c7a2c

- Fix to_date's handling of year 519.  A thinko in commit
  029dfdf1157b6d837a7b7211cd35b00c6bcd767c caused the year 519 to be
  handled differently from either adjacent year, which was not the
  intention AFAICS.  Report and diagnosis by Marc Cousin.  In passing,
  remove redundant re-tests of year value.
  http://git.postgresql.org/pg/commitdiff/41f4a0ab789463971add986dbc778d77ec5a0ef4

Heikki Linnakangas pushed:

- Fix pg_upgrade, broken by the xlogid/segno -> 64-bit int
  refactoring.  The xlogid + segno representation of a particular WAL
  segment doesn't make much sense in pg_resetxlog anymore, now that we
  don't use that anywhere else. Use the WAL filename instead, since
  that's a convenient way to name a particular WAL segment.  I did
  this partially for pg_resetxlog in the original xlogid/segno ->
  uint64 patch, but I neglected pg_upgrade and the docs. This should
  now be more complete.
  http://git.postgresql.org/pg/commitdiff/038f3a05092365eca070bdc588554520dfd5ffb9

- I neglected many comments in the log+seg -> 64-bit segno patch. Fix.
  Reported by Amit Kapila.
  http://git.postgresql.org/pg/commitdiff/ec786c6c81bfa1067319305ff84b862eba3b2f27

- Fix two more neglected comments, still referring to log/seg.  Fujii
  Masao
  http://git.postgresql.org/pg/commitdiff/a8f97b39c70e831ced842eb7e41f810bee63e431

- Update outdated commit; xlp_rem_len field is in page header now.
  Spotted by Amit Kapila
  http://git.postgresql.org/pg/commitdiff/8f85667a860437c50ae13008cad5359909388d3e

- Initialize shared memory copy of ckptXidEpoch correctly when not in
  recovery.  This bug was introduced by commit
  20d98ab6e4110087d1816cd105a40fcc8ce0a307, so backpatch this to
  9.0-9.2 like that one.  This fixes bug #6710, reported by Tarvi
  Pillessaar
  http://git.postgresql.org/pg/commitdiff/7a5c9ca93ad7d9b84f612d6157bf8990c7041d3c

- Validate xlog record header before enlarging the work area to store
  it.  If the record header is garbled, we're now quite likely to
  notice it before we try to make a bogus memory allocation and run
  out of memory. That can still happen, if the xlog record is split
  across pages (we cannot verify the record header until reading the
  next page in that scenario), but this reduces the chances. An
  out-of-memory is treated as a corrupt record anyway, so this isn't a
  correctness issue, just a case of giving a better error message.
  Per Amit Kapila's suggestion.
  http://git.postgresql.org/pg/commitdiff/567787f216da750b3805aea6fd8aef19e8b882a1

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Alvaro Herrera and Kevin Grittner traded patches to implement foreign
key locks.

Alvaro Herrera and Zoltan Boszormenyi traded patches to implement a
lock_timeout and SIGALARM framework.

Ryan Kelly sent in another revision of the patch to allow breaking out
of hung connection attempts in psql.

KaiGai Kohei and Etsuro Fujita traded new revisions of the patch to
add an option to allow selective binary conversion for CSV foreign
tables.

Satoshi Nagayasu sent in two revisions of a patch to add a
pg_stat_lwlocks system view.

Pavel Stehule sent in a PoC patch to see psql client-side variables in
SQL.

Pavel Stehule sent in another revision of the patch to add a way to
check PL/pgsql functions.

Fujii Masao sent in another revision of the patch to report the WAL
file containing checkpoint's REDO record in pg_controldata output.

Nils Goroll sent in three revisions of a patch to replace s_lock
spinlock code with pthread_mutex on linux.

Andres Freund sent in three revisions of a patch to add an embedded
list to the back-end.

Fujii Masao sent in two revisions of a patch to keep pg_basebackup
from blocking all queries, which resulted in horrible performance.

Magnus Hagander sent in three revisions of a patch to output the part
of the pg_hba.conf that's erroring out.

Josh Kupershmidt sent in two revisions of a patch to make
pg_signal_backend() symmetric with respect to database
super-user-ness.

Peter Eisentraut sent in a patch to ensure that initdb only errors out
asking for a password in cases where PostgreSQL would control that
password.

Alex Hunsaker and Marco Nenciarini traded patches to add
array_remove() and array_replace() functions.

Peter Eisentraut sent in a patch to make static code analyzers happier
about elog/ereport's not returning anything.

Alexander Korotkov sent in another revision of the patch to add
conversion from pg_wchar to multibyte.

Zoltan Boszormenyi sent in a patch to make pg_basebackup configure and
start the standby.

Dean Rasheed sent in a PoC patch to implement updateable views.

Peter Geoghegan sent in two more revisions of a patch to enhance the
data structure on which error messages are based.

Dimitri Fontaine sent in another revision of the patch to add event
triggers.  Thom Brown responded with some corrections of the included
docs.

Robert Haas sent in a patch to demote "implicit creation" messages,
quieting, at the default logging level, output for the operations
that cause them.

Amit Kapila sent in a patch to unify the parsing of pg_ident.conf and
pg_hba.conf.

KaiGai Kohei sent in a patch to track the user ID from when a portal
was started in case of changes.