== PostgreSQL Weekly News - September 11 2016 ==

== PostgreSQL Weekly News - September 11 2016 ==

The Korean Users Group will hold its first PGDay event on October 15, 2016 in Seoul.
http://pgday.postgresql.kr/

PGDay Austin 2016, will take place on November 12, 2016. Submission deadline
is September 21, 2016 by midnight CST. Details and submission form at:
https://www.postgresql.us/events/2016/austin

PGDay.IT 2016 will take place in Prato on December the 13th 2016.
http://pgday.it

== PostgreSQL Product News ==

pgloader 3.3.1, a bulk loader for PostgreSQL, released.
http://pgloader.io/

pgBadger v9.0, a PostgreSQL log analyzer and graph tool written in
Perl, released.
https://github.com/dalibo/pgbadger/releases/

PostGIS 2.3.0beta1, the industry standard geographic information
system package for PostgreSQL, released.
http://postgis.net/

PGroonga 1.1.1, a full text search platform for all languages, released.
http://groonga.org/en/blog/2016/08/31/pgroonga-1.1.1.html

== PostgreSQL Jobs for September ==

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

== PostgreSQL Local ==

PostgresOpen 2016 in will be held in Dallas, Texas September 13-16.
https://2016.postgresopen.org/

PostgreSQL Session will be held on September 22th, 2016, in Lyon,
France.
http://blog.dalibo.com/2016/05/13/CFP-pgsession-lyon.html

Postgres Vision 2016 will be held October 11-13, 2016, in San Francisco.
http://postgresvision.com/

PostgreSQL Conference Europe will take place in Tallin, Estonia, on
November 1-4, 2016. Early bird registration is open until September
14th, 2016.
http://2016.pgconf.eu/registration/

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

CHAR(16) will take place in New York, December 6, 2016. Call for
papers is open until midnight (EDT) September 13, 2016.
http://charconference.org/

== PostgreSQL in the News ==

Planet PostgreSQL: http://planet.postgresql.org/

PostgreSQL Weekly News is brought to you this week by David Fetter

Submit news and announcements by Sunday at 3:00pm Pacific time.
Please send English language ones to david(at)fetter(dot)org, German language
to pwn(at)pgug(dot)de, Italian language to pwn(at)itpug(dot)org(dot)

== Applied Patches ==

Simon Riggs pushed:

- Dirty replication slots when using sql interface. When
pg_logical_slot_get_changes(...) sets confirmed_flush_lsn to the point at
which replay stopped, it doesn't dirty the replication slot. So if the replay
didn't cause restart_lsn or catalog_xmin to change as well, this change will
not get written out to disk. Even on a clean shutdown. If Pg crashes or
restarts, a subsequent pg_logical_slot_get_changes(...) call will see the same
changes already replayed since it uses the slot's confirmed_flush_lsn as the
start point for fetching changes. The caller can't specify a start LSN when
using the SQL interface. Mark the slot as dirty after reading changes using
the SQL interface so that users won't see repeated changes after a clean
shutdown. Repeated changes still occur when using the walsender interface or
after an unclean shutdown. Craig Ringer
http://git.postgresql.org/pg/commitdiff/d851bef2d60ff9345249ff67c053e37fe4b364cc

- Document LSN acronym in WAL Internals. We previously didn't mention what an
LSN actually was. Simon Riggs and Michael Paquier
http://git.postgresql.org/pg/commitdiff/ec03f4121cec6cf885bf40d9dfb53b8368251e99

- Add debug check function LWLockHeldByMeInMode(). Tests whether my process
holds a lock in given mode. Add initial usage in MarkBufferDirty(). Thomas
Munro
http://git.postgresql.org/pg/commitdiff/016abf1fb8333de82a259af0cc7572a4b868023b

- Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL. lazy_truncate_heap() was waiting for
VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds not milliseconds as
originally intended. Found by code inspection. Simon Riggs
http://git.postgresql.org/pg/commitdiff/dcb12ce8d8691e0e526d3f38d14c4d7fc9c664f5

- Fix minor memory leak in Standby startup.
StandbyRecoverPreparedTransactions() leaked the buffer used for two phase
state file. This was leaked once at startup and at every shutdown checkpoint
seen. Backpatch to 9.6 Stas Kelvich
http://git.postgresql.org/pg/commitdiff/67c6bd1ca3ce75778138bf4713444a5a6b46032e

- Correct TABLESAMPLE docs. Revert to original use of word “sample”, though
with clarification, per Tom Lane. Discussion: 29052(dot)1471015383(at)sss(dot)pgh(dot)pa(dot)us
http://git.postgresql.org/pg/commitdiff/f66472428a51fc484bc5ca81791924d06a6f096d

- Fix corruption of 2PC recovery with subxacts. Reading 2PC state files during
recovery was borked, causing corruptions during recovery. Effect limited to
servers with 2PC, subtransactions and recovery/replication. Stas Kelvich,
reviewed by Michael Paquier and Pavan Deolasee
http://git.postgresql.org/pg/commitdiff/ec253de1fd2e6002122de80815ac5b963af8277c

Tom Lane pushed:

- Relax transactional restrictions on ALTER TYPE ... ADD VALUE. To prevent
possibly breaking indexes on enum columns, we must keep uncommitted enum
values from getting stored in tables, unless we can be sure that any such
column is new in the current transaction. Formerly, we enforced this by
disallowing ALTER TYPE ... ADD VALUE from being executed at all in a
transaction block, unless the target enum type had been created in the current
transaction. This patch removes that restriction, and instead insists that an
uncommitted enum value can't be referenced unless it belongs to an enum type
created in the same transaction as the value. Per discussion, this should be
a bit less onerous. It does require each function that could possibly return
a new enum value to SQL operations to check this restriction, but there aren't
so many of those that this seems unmaintainable. Andrew Dunstan and Tom Lane
Discussion: <4075(dot)1459088427(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/15bc038f9bcd1a9af3f625caffafc7c20322202d

- Make locale-dependent regex character classes work for large char codes.
Previously, we failed to recognize Unicode characters above U+7FF as being
members of locale-dependent character classes such as [[:alpha:]]. (Actually,
the same problem occurs for large pg_wchar values in any multibyte encoding,
but UTF8 is the only case people have actually complained about.) It's
impractical to get Spencer's original code to handle character classes or
ranges containing many thousands of characters, because it insists on
considering each member character individually at regex compile time, whether
or not the character will ever be of interest at run time. To fix, choose a
cutoff point MAX_SIMPLE_CHR below which we process characters individually as
before, and deal with entire ranges or classes as single entities above that.
We can actually make things cheaper than before for chars below the cutoff,
because the color map can now be a simple linear array for those chars, rather
than the multilevel tree structure Spencer designed. It's more expensive than
before for chars above the cutoff, because we must do a binary search in a
list of high chars and char ranges used in the regex pattern, plus call
iswalpha() and friends for each locale-dependent character class used in the
pattern. However, multibyte encodings are normally designed to give smaller
codes to popular characters, so that we can expect that the slow path will be
taken relatively infrequently. In any case, the speed penalty appears minor
except when we have to apply iswalpha() etc. to high character codes at
runtime --- and the previous coding gave wrong answers for those cases, so
whether it was faster is moot. Tom Lane, reviewed by Heikki Linnakangas
Discussion: <15563(dot)1471913698(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/c54159d44ceaba26ceda9fea1804f0de122a8f30

- Cosmetic code cleanup in commands/extension.c. Some of the comments added by
the CREATE EXTENSION CASCADE patch were a bit sloppy, and I didn't care for
redeclaring the same local variable inside a nested block either. No
functional changes.
http://git.postgresql.org/pg/commitdiff/25794e841e5b86a0f90fac7f7f851e5d950e51e2

- Repair whitespace in initdb message. What used to be four spaces somehow
turned into a tab and a couple of spaces in commit a00c58314, no doubt from
overhelpful emacs autoindent. Noted by Peter Eisentraut.
http://git.postgresql.org/pg/commitdiff/a2ee579b6def8e0bde876c6c2fc9d4b8ec2b6b67

- Teach appendShellString() to not quote strings containing "-". Brain fade in
commit a00c58314: I was thinking that a string starting with "-" could be
taken as a switch depending on command line syntax. That's true, but having
appendShellString() quote it will not help, so we may as well not do so. Per
complaint from Peter Eisentraut.
http://git.postgresql.org/pg/commitdiff/cdc70597c9ba62aad08a46e55c0c783bf4c21c9c

- Guard against possible memory allocation botch in batchmemtuples(). Negative
availMemLessRefund would be problematic. It's not entirely clear whether the
case can be hit in the code as it stands, but this seems like good
future-proofing in any case. While we're at it, insist that the value be not
merely positive but not tiny, so as to avoid doing a lot of repalloc work for
little gain. Peter Geoghegan Discussion:
<CAM3SWZRVkuUB68DbAkgw=532gW0f+fofKueAMsY7hVYi68MuYQ(at)mail(dot)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/f032722f86a709277d44a317a3bc8acd74861a72

- Doc: small improvements for documentation about VACUUM freezing. Mostly,
explain how row xmin's used to be replaced by FrozenTransactionId and no
longer are. Do a little copy-editing on the side. Per discussion with Egor
Rogov. Back-patch to 9.4 where the behavioral change occurred. Discussion:
<575D7955(dot)6060209(at)postgrespro(dot)ru>
http://git.postgresql.org/pg/commitdiff/975768f8eae2581b89ceafe8b16a77ff375207fe

- Add a HINT for client-vs-server COPY failure cases. Users often get confused
between COPY and \copy and try to use client-side paths with COPY. The server
then cannot find the file (if remote), or sees a permissions problem (if
local), or some variant of that. Emit a hint about this in the most common
cases. In future we might want to expand the set of errnos for which the hint
gets printed, but be conservative for now. Craig Ringer, reviewed by
Christoph Berg and Tom Lane Discussion:
<CAMsr+YEqtD97qPEzQDqrCt5QiqPbWP_X4hmvy2pQzWC0GWiyPA(at)mail(dot)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/4f405c8ef4704b7fa7fd8ac14a66c5f5d13722c4

- Doc: minor documentation improvements about extensions. Document the
formerly-undocumented behavior that schema and comment control-file entries
for an extension are honored only during initial installation, whereas other
properties are also honored during updates. While at it, do some copy-editing
on the recently-added docs for CREATE EXTENSION ... CASCADE, use links for
some formerly vague cross references, and make a couple other minor
improvements. Back-patch to 9.6 where CASCADE was added. The other parts of
this could go further back, but they're probably not important enough to
bother.
http://git.postgresql.org/pg/commitdiff/bd180b607927c7757af17cd6fce0e545e5c48584

- Support renaming an existing value of an enum type. Not much to be said about
this patch: it does what it says on the tin. In passing, rename
AlterEnumStmt.skipIfExists to skipIfNewValExists to clarify what it actually
does. In the discussion of this patch we considered supporting other similar
options, such as IF EXISTS on the type as a whole or IF NOT EXISTS on the
target name. This patch doesn't actually add any such feature, but it might
happen later. Dagfinn Ilmari Mannsåker, reviewed by Emre Hasegeli Discussion:
<CAO=2mx6uvgPaPDf-rHqG8=1MZnGyVDMQeh8zS4euRyyg4D35OQ(at)mail(dot)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/0ab9c56d0fe3acc9d4717a9cbac6ef3369275b90

- Don't print database's tablespace in pg_dump -C --no-tablespaces output. If
the database has a non-default tablespace, we emitted a TABLESPACE clause in
the CREATE DATABASE command emitted by -C, even if --no-tablespaces was also
specified. This seems wrong, and it's inconsistent with what pg_dumpall does,
so change it. Per bug #14315 from Danylo Hlynskyi. Back-patch to 9.5. The
bug is much older, but it'd be a more invasive change before 9.5 because
dumpDatabase() hasn't got an easy way to get to the outputNoTablespaces flag.
Doesn't seem worth the work given the lack of previous complaints. Report:
<20160908081953(dot)1402(dot)75347(at)wrigleys(dot)postgresql(dot)org>
http://git.postgresql.org/pg/commitdiff/e97e9c57bd22b2dfbfaf41f7d5c69789f7fad554

- Allow pg_dump to dump non-extension members of an extension-owned schema.
Previously, if a schema was created by an extension, a normal pg_dump run (not
--binary-upgrade) would summarily skip every object in that schema. In a case
where an extension creates a schema and then users create other objects within
that schema, this does the wrong thing: we want pg_dump to skip the schema but
still create the non-extension-owned objects. There's no easy way to fix this
pre-9.6, because in earlier versions the "dump" status for a schema is just a
bool and there's no way to distinguish "dump me" from "dump my members".
However, as of 9.6 we do have enough state to represent that, so this is a
simple correction of the logic in selectDumpableNamespace. In passing, make
some cosmetic fixes in nearby code. Martín Marqués, reviewed by Michael
Paquier Discussion: <99581032-71de-6466-c325-069861f1947d(at)2ndquadrant(dot)com>
http://git.postgresql.org/pg/commitdiff/df5d9bb8d5074138e6fea63ac8acd9b95a0eb859

- Avoid reporting "cache lookup failed" for some user-reachable cases. We have
a not-terribly-thoroughly-enforced-yet project policy that internal errors
with SQLSTATE XX000 (ie, plain elog) should not be triggerable from SQL.
record_in, domain_in, and PL validator functions all failed to meet this
standard, because they threw plain elog("cache lookup failed for XXX") errors
on bad OIDs, and those are all invokable from SQL. For record_in, the best
fix is to upgrade typcache.c (lookup_type_cache) to throw a user-facing error
for this case. That seems consistent because it was more than halfway there
already, having user-facing errors for shell types and non-composite types.
Having done that, tweak domain_in to rely on the typcache to throw an
appropriate error. (This costs little because InitDomainConstraintRef would
fetch the typcache entry anyway.) For the PL validator functions, we already
have a single choke point at CheckFunctionValidatorAccess, so just fix its
error to be user-facing. Dilip Kumar, reviewed by Haribabu Kommi Discussion:
<87wpxfygg9(dot)fsf(at)credativ(dot)de>
http://git.postgresql.org/pg/commitdiff/967a7b0fc9c8f4e07b697148238566203cb060de

- In PageIndexTupleDelete, don't assume stored item lengths are MAXALIGNed.
PageAddItem stores the item length as-is. It MAXALIGN's the amount of space
actually allocated for each tuple, but not the stored length.
PageRepairFragmentation, PageIndexMultiDelete, and PageIndexDeleteNoCompact
are all on board with this and MAXALIGN item lengths after fetching them. But
PageIndexTupleDelete expects the stored length to be a MAXALIGN multiple
already. This accidentally works for existing index AMs because they all
maxalign their tuple sizes internally; but we don't do that for heap tuples,
and it shouldn't be a requirement for index tuples either. So, sync
PageIndexTupleDelete with the rest of bufpage.c by having it maxalign the item
size after fetching. Also add a check that pd_special is maxaligned, to
ensure that the test "(offset + size) > phdr->pd_special" is still doing the
right thing. (If offset and pd_special are aligned, it doesn't matter whether
size is.) Again, this is in sync with the rest of the routines here, except
for PageAddItem which doesn't test because it doesn't actually do anything for
which pd_special alignment matters. This shouldn't have any immediate
functional impact; it just adds the flexibility to use PageIndexTupleDelete on
index tuples with non-aligned lengths. Discussion:
<3814(dot)1473366762(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/984d0a14e8d0141a68da5bd56ce6821042298904

- Invent PageIndexTupleOverwrite, and teach BRIN and GiST to use it.
PageIndexTupleOverwrite performs approximately the same function as
PageIndexTupleDelete (or PageIndexDeleteNoCompact) followed by PageAddItem
targeting the same item pointer offset. But in the case where the new tuple
is the same size as the old, it avoids shuffling other data around on the
page, because the new tuple is placed where the old one was rather than being
appended to the end of the page. This has been shown to provide a substantial
speedup for some GiST use-cases. Also, this change allows some API
simplifications: we can get rid of the rather klugy and error-prone
PAI_ALLOW_FAR_OFFSET flag for PageAddItemExtended, since that was used only to
cover a corner case for BRIN that's better expressed by using
PageIndexTupleOverwrite. Note that this patch causes a rather subtle WAL
incompatibility: the physical page content change represented by certain WAL
records is now different than it was before, because while the tuples have the
same itempointer line numbers, the tuples themselves are in different places.
I have not bumped the WAL version number because I think it doesn't matter
unless you are trying to do bitwise comparisons of original and replayed
pages, and in any case we're early in a devel cycle and there will probably be
more WAL changes before v10 gets out the door. There is probably room to make
use of PageIndexTupleOverwrite in SP-GiST and GIN too, but that is left for a
future patch. Andrey Borodin, reviewed by Anastasia Lubennikova, whacked
around a bit by me Discussion:
<CAJEAwVGQjGGOj6mMSgMwGvtFd5Kwe6VFAxY=uEPZWMDjzbn4VQ(at)mail(dot)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/b1328d78f88cdf4f7504004159e530b776f0de16

- Convert PageAddItem into a macro to save a few cycles. Nowadays this is just
a backwards-compatibility wrapper around PageAddItemExtended, so let's avoid
the extra level of function call. In addition, because pretty much all
callers are passing constants for the two bool arguments, compilers will be
able to constant-fold the conversion to a flags bitmask. Discussion:
<552(dot)1473445163(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/1a4be103a523db8d47b464463ba175cc664442b2

- Rewrite PageIndexDeleteNoCompact into a form that only deletes 1 tuple. The
full generality of deleting an arbitrary number of tuples is no longer needed,
so let's save some code and cycles by replacing the original coding with an
implementation based on PageIndexTupleDelete. We can always get back the old
code from git if we need it again for new callers (though I don't care for its
willingness to mess with line pointers it wasn't told to mess with).
Discussion: <552(dot)1473445163(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/24992c6db9fd40f342db1f22747ec9e56483796d

- Fix miserable coding in pg_stat_get_activity(). Commit dd1a3bccc replaced a
test on whether a subroutine returned a null pointer with a test on whether
&pointer->backendStatus was null. This accidentally failed to fail, at least
on common compilers, because backendStatus is the first field in the struct;
but it was surely trouble waiting to happen. Commit f91feba87 then messed
things up further, changing the logic to local_beentry =
pgstat_fetch_stat_local_beentry(curr_backend); if (!local_beentry) continue;
beentry = &local_beentry->backendStatus; if (!beentry) { where the second "if"
is now dead code, so that the intended behavior of printing a row with
"<backend information not available>" cannot occur. I suspect this is all
moot because pgstat_fetch_stat_local_beentry will never actually return null
in this function's usage, but it's still very poor coding. Repair back to 9.4
where the original problem was introduced.
http://git.postgresql.org/pg/commitdiff/ddc889317912fd8b654439701195a43cecfd4e79

- Improve unreachability recognition in elog() macro. Some experimentation with
an older version of gcc showed that it is able to determine whether "if
(elevel_ >= ERROR)" is compile-time constant if elevel_ is declared "const",
but otherwise not so much. We had accounted for that in ereport() but were
too miserly with braces to make it so in elog(). I don't know how many
currently-interesting compilers have the same quirk, but in case it will save
some code space, let's make sure that elog() is on the same footing as
ereport() for this purpose. Back-patch to 9.3 where we introduced
pg_unreachable() calls into elog/ereport.
http://git.postgresql.org/pg/commitdiff/f2717c79eeecaf5997016d52fd81881301dcfc5e

- Fix and simplify MSVC build's handling of xml/xslt/uuid dependencies.
Solution.pm mistakenly believed that the xml option requires the xslt option,
when actually the dependency is the other way around; and it believed that
libxml requires libiconv, which is not necessarily so, so we shouldn't enforce
it here. Fix the option cross-checking logic. Also, since AddProject already
takes care of adding libxml and libxslt include and library dependencies to
every project, there's no need for the custom code that did that in mkvcbuild.
While at it, let's handle the similar dependencies for uuid in a similar
fashion. Given the lack of field complaints about these overly strict build
dependency requirements, there seems no need for a back-patch. Michael
Paquier Discussion:
<CAB7nPqR0+gpu3mRQvFjf-V-bMxmiSJ6NpTg9_WzVDL+a31cV2g(at)mail(dot)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/28e5e5648cc3666537c393b2636c4aa34fdb22c1

- Allow CREATE EXTENSION to follow extension update paths. Previously, to
update an extension you had to produce both a version-update script and a new
base installation script. It's become more and more obvious that that's
tedious, duplicative, and error-prone. This patch attempts to improve matters
by allowing the new base installation script to be omitted. CREATE EXTENSION
will install a requested version if it can find a base script and a chain of
update scripts that will get there. As in the existing update logic, shorter
chains are preferred if there's more than one possibility, with an arbitrary
tie-break rule for chains of equal length. Also adjust the
pg_available_extension_versions view to show such versions as installable.
While at it, refactor the code so that CASCADE processing works for extensions
requested during ApplyExtensionUpdates(). Without this, addition of a new
requirement in an updated extension would require creating a new base script,
even if there was no other reason to do that. (It would be easy at this point
to add a CASCADE option to ALTER EXTENSION UPDATE, to allow the same thing to
happen during a manually-commanded version update, but I have not done that
here.) Tom Lane, reviewed by Andres Freund Discussion:
<20160905005919(dot)jz2m2yh3und2dsuy(at)alap3(dot)anarazel(dot)de>
http://git.postgresql.org/pg/commitdiff/40b449ae84dcf71177d7749a7b0c582b64dc15f0

Bruce Momjian pushed:

- C comment: align dashes in GroupState node header. Author: Jim Nasby
http://git.postgresql.org/pg/commitdiff/f80049f76a32858601510eaaef19ab8160e4c9b3

- C comment: fix file name mention on line 1. Author: Amit Langote
http://git.postgresql.org/pg/commitdiff/67e1e2aaff109c507da013c66009f048dda96f3e

- 9.6 release notes: correct summary item about freeze Previously it less
precisely talked about autovacuum. Backpatch-through: 9.6
http://git.postgresql.org/pg/commitdiff/c9cf432ef32a9d29323b9b079178c1a6be126ff8

Álvaro Herrera pushed:

- Have "make coverage" recurse into contrib as well
http://git.postgresql.org/pg/commitdiff/2093f6630500c9d5e122748ac7d3719855d71174

- Fix two src/test/modules Makefiles. commit_ts and test_pg_dump were
declaring targets before including the PGXS stanza, which meant that the "all"
target customarily defined as the first (and therefore default target) was not
the default anymore. Fix that by moving those target definitions to after
PGXS. commit_ts was initially good, but I broke it in commit 9def031bd2;
test_pg_dump was born broken, probably copying from commit_ts' mistake. In
passing, fix a comment mistake in test_pg_dump/Makefile. Backpatch to 9.6.
Noted by Tom Lane.
http://git.postgresql.org/pg/commitdiff/19acee8c5adb68b96222e41c084efbc9b31d397a

- Fix locking a tuple updated by an aborted (sub)transaction. When
heap_lock_tuple decides to follow the update chain, it tried to also lock any
version of the tuple that was created by an update that was subsequently
rolled back. This is pointless, since for all intents and purposes that tuple
exists no more; and moreover it causes misbehavior, as reported independently
by Marko Tiikkaja and Marti Raudsepp: some SELECT FOR UPDATE/SHARE queries may
fail to return the tuples, and assertion-enabled builds crash. Fix by having
heap_lock_updated_tuple test the xmin and return success immediately if the
tuple was created by an aborted transaction. The condition where tuples
become invisible occurs when an updated tuple chain is followed by
heap_lock_updated_tuple, which reports the problem as HeapTupleSelfUpdated to
its caller heap_lock_tuple, which in turn propagates that code outwards
possibly leading the calling code (ExecLockRows) to believe that the tuple
exists no longer. Backpatch to 9.3. Only on 9.5 and newer this leads to a
visible failure, because of commit 27846f02c176; before that, heap_lock_tuple
skips the whole dance when the tuple is already locked by the same
transaction, because of the ancient HeapTupleSatisfiesUpdate behavior. Still,
the buggy condition may also exist in more convoluted scenarios involving
concurrent transactions, so it seems safer to fix the bug in the old branches
too. Discussion:
https://www.postgresql.org/message-id/CABRT9RC81YUf1=jsmWopcKJEro=VoeG2ou6sPwyOUTx_qteRsg@mail.gmail.com
https://www.postgresql.org/message-id/48d3eade-98d3-8b9a-477e-1a8dc32a724d@joh.to
http://git.postgresql.org/pg/commitdiff/5c609a742f294907512b946dbaf1feaa3b71ddc7

Peter Eisentraut pushed:

- Add location field to DefElem. Add a location field to the DefElem struct,
used to parse many utility commands. Update various error messages to supply
error position information. To propogate the error position information in a
more systematic way, create a ParseState in standard_ProcessUtility() and pass
that to interested functions implementing the utility commands. This seems
better than passing the query string and then reassembling a parse state ad
hoc, which violates the encapsulation of the ParseState type. Reviewed-by:
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/49eb0fd0972d14014dd3533b1f1bf8c94c899883

- Make better use of existing enums in plpgsql plpgsql.h defines a number of
enums, but most of the code passes them around as ints. Update structs and
function prototypes to take enum types instead. This clarifies the struct
definitions in plpgsql.h in particular. Reviewed-by: Pavel Stehule
<pavel(dot)stehule(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/e0013deb5983303d945aacd56909ac4ce227fde1

Noah Misch pushed:

- MSVC: Place gendef.pl temporary file in the target directory. Until now, it
used the current working directory. This makes it safe for simultaneous
invocations of gendef.pl, with different target directories, to run from a
single current working directory, such as $(top_srcdir). The MSVC build
system will soon rely on this. Christian Ullrich, reviewed by Michael
Paquier.
http://git.postgresql.org/pg/commitdiff/976a9bbd0251ea112898f85314646801e7e6207d

- MSVC: Pass any user-set MSBFLAGS to MSBuild and VCBUILD. This is particularly
useful to pass /m, to perform a parallel build. Christian Ullrich, reviewed
by Michael Paquier.
http://git.postgresql.org/pg/commitdiff/d299eb41dfc7b73dec80f22554b952f01c9d54a4

Andres Freund pushed:

- Fix mdtruncate() to close fd.c handle of deleted segments. mdtruncate()
forgot to FileClose() a segment's mdfd_vfd, when deleting it. That lead to a
fd.c handle to a truncated file being kept open until backend exit. The issue
appears to have been introduced way back in 1a5c450f3024ac5, before that the
handle was closed inside FileUnlink(). The impact of this bug is limited -
only VACUUM and ON COMMIT TRUNCATE for temporary tables, truncate files in
place (i.e. TRUNCATE itself is not affected), and the relation has to be
bigger than 1GB. The consequences of a leaked fd.c handle aren't severe
either. Discussion: <20160908220748(dot)oqh37ukwqqncbl3n(at)alap3(dot)anarazel(dot)de>
Backpatch: all supported releases
http://git.postgresql.org/pg/commitdiff/769fd9d8e06bf862334a0e04134a3d2c665e5e5b

- Improve scalability of md.c for large relations. So far md.c used a linked
list of segments. That proved to be a problem when processing large relations,
because every smgr.c/md.c level access to a page incurred walking through a
linked list of all preceding segments. Thus making accessing pages
O(#segments). Replace the linked list of segments hanging off
SMgrRelationData with an array of opened segments. That allows O(1) access to
individual segments, if they've previously been opened. Discussion:
<20140331101001(dot)GE13135(at)alap3(dot)anarazel(dot)de> Reviewed-By: Peter Geoghegan, Tom
Lane (in an older version)
http://git.postgresql.org/pg/commitdiff/45e191e3aa62d47a8bc1a33f784286b2051f45cb

- Faster PageIsVerified() for the all zeroes case. That's primarily useful for
testing very large relations, using sparse files. Discussion:
<20140331101001(dot)GE13135(at)alap3(dot)anarazel(dot)de> Reviewed-By: Peter Geoghegan
http://git.postgresql.org/pg/commitdiff/417fefaf089fc0b73607cbbe8bcd0bc9e89d08ef

Heikki Linnakangas pushed:

- Implement binary heap replace-top operation in a smarter way. In external
sort's merge phase, we maintain a binary heap holding the next tuple from each
input tape. On each step, the topmost tuple is returned, and replaced with the
next tuple from the same tape. We were doing the replacement by deleting the
top node in one operation, and inserting the next tuple after that. However,
you can do a "replace-top" operation more efficiently, in one "sift-up". A
deletion will always walk the heap from top to bottom, but in a replacement,
we can stop as soon as we find the right place for the new tuple. This is
particularly helpful, if the tapes are not in completely random order, so that
the next tuple from a tape is likely to land near the top of the heap. Peter
Geoghegan, reviewed by Claudio Freire, with some editing by me. Discussion:
<CAM3SWZRhBhiknTF_=NjDSnNZ11hx=U_SEYwbc5vd=x7M4mMiCw(at)mail(dot)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/24598337c8d214ba8dcf354130b72c49636bba69

== Pending Patches ==

Michaël Paquier and Christian Ullrich traded patches to enable parallel builds
with MSVC.

Haribabu Kommi sent in another revision of a patch to add a pg_hba_file_settings system
view.

Craig Ringer sent in a patch to send catalog_xmin in hot standby feedback
protocol, make walsender respect catalog_xmin in hot standby feedback messages,
allow GetOldestXmin(...) to optionally disregard the catalog_xmin, and send
catalog_xmin separately in hot_standby_feedback messages.

Heikki Linnakangas sent in a patch to fix compilation with OpenSSL 1.1 and
silence deprecation warnings with OpenSSL 1.1.

Abhijit Menon-Sen sent in another revision of a patch to convert recovery.conf
settings to GUCs.

KaiGai Kohei sent in another revision of a patch to implement PassDownLimitBound
for ForeignScan/CustomScan.

Michaël Paquier sent in another revision of a patch to speed up 2PC
transactions.

Mithun Cy sent in another revision of a patch to cache hash index meta pages.

Craig Ringer and Vladimir Gordiychuk traded patches to respect client-initiated
CopyDone in walsender and allow streaming to be interrupted during
ReorderBufferCommit.

Claudio Freire, Masahiko Sawada, and Simon Riggs traded patches to enable using
over 1GB of work_mem in VACUUM.

Tom Lane sent in two revisions of a patch to let CREATE EXTENSION follow update
chains.

Simon Riggs sent in another revision of a patch to add a "patient" mode to LOCK
TABLE.

Daniel Vérité sent in another revision of a patch to add batch/pipelining
support for libpq.

Michaël Paquier and Christian Ullrich traded patches to do some cleanups in
pgwin32_putenv, fix the load race in pgwin32_putenv() (and open the unload
race), and pin any DLL as soon as seen when looking for _putenv on Windows.

Vinayak Pokale sent in a patch to add pg_fdw_xact_resolver().

Gerdan Rezende dos Santos sent in another revision of a patch to add an option
to pg_dumpall to exclude tables from the dump.

Kyotaro HORIGUCHI sent in a patch to fix an illegal SJIS mapping.

Etsuro Fujita sent in another revision of a patch to push more UPDATEs and
DELETEs to the PostgreSQL FDW.

Ashutosh Bapat and Amit Langote traded patches to add declarative table
partitioning.

Kyotaro HORIGUCHI sent in another revision of a patch to add IF NOT EXISTS
support to psql's tab completion.

David Steele sent in two more revisions of a patch to exclude additional
directories in pg_basebackup.

Pavan Deolasee sent in a patch to override compile time log levels of specific
messages/modules.

Heikki Linnakangas sent in four revisions of a patch to remove tuplesort merge
pre-reading.

Fabien COELHO sent in another revision of a patch to pgbench to permit storing
select results into variables.

Peter Geoghegan sent in another revision of a patch to add amcheck, a B-Tree
integrity checking tool.

Jim Nasby sent in another revision of a patch to fix a mistaken comment in
nodeCtescan.c.

Vik Fearing sent in two more revisions of a patch to add long options for pg_ctl
waiting.

Kyotaro HORIGUCHI sent in a PoC patch to use a radix tree to encoding characters
of Shift JIS.

Michaël Paquier sent in another revision of a patch to forbid the use of LF and
CR characters in database and role names.

Ildar Musin sent in another revision of a patch to enable index-only scans for
some expressions.

Amit Kapila sent in another revision of a patch to enable WAL logging for hash
indexes.

Michaël Paquier sent in three revisions of a patch to remove a useless
dependency assumption libxml2 -> libxslt in MSVC scripts.

Kuntal Ghosh sent in two more revisions of a patch to add a WAL consistency
check facility.

Masahiko Sawada sent in a patch to make lazy_scan_heap output how many
all_frozen pages are skipped and add cheat_vacuum_table_size.

Rahila Syed sent in another revision of a patch to get psql to error out when
someone tries to set autocommit at the wrong spot.

Ashutosh Bapat sent in another revision of a patch to enable pushing aggregates
to a foreign server.

Masahiko Sawada sent in a patch to add a --disable-page-skipping option to the
vacuumdb command.

Peter Eisentraut sent in another revision of a patch to add overflow checks to
the money type input function.

Victor Wagner sent in another revision of a patch to implement failover on libpq
connect level.

Stephen Frost sent in another revision of a patch to add support for restrictive
RLS policies.

Petr Jelinek sent in another revision of a patch to implement logical
replication.

Adam Brightwell sent in a patch to fix a mismatch between RLS and COPY.

Andrew Borodin and Mikhail Bakhterev traded patches to improve the GiST penalty
functions.

Peter Eisentraut sent in another revision of a patch to add CREATE SEQUENCE AS
<data type> clause.

Ashutosh Bapat sent in a patch to support partition-wise joins for partitioned
tables.

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

Pavel Stehule sent in two more revisions of a patch to add xmltable().

Kevin Grittner sent in another revision of a patch to add trigger transition
tables.

Thomas Munro sent in another revision of a patch to use kqeue when available.

Dmitry Dolgov sent in a patch to add generic type subscription.

Heikki Linnakangas sent in a patch to allow temp file access tracing.

Vitaly Burovoy sent in another revision of a patch to add tab completion for
CREATE DATABASE ... TEMPLATE ... to psql.

Amit Kapila sent in a patch to add some simple tests for pg_stat_statements.

Mattia sent in a patch to allow to_date() and to_timestamp() to accept localized
month names.

Corey Huinker sent in another revision of a patch to let file_fdw access COPY
FROM PROGRAM.

Peter Eisentraut sent in another revision of a patch to add a pg_sequences view.

Peter Geoghegan sent in another revision of a patch to add parallel tuplesort
for parallel B-tree index creation.