== PostgreSQL Weekly News - April 10 2016 ==

== PostgreSQL Weekly News - April 10 2016 ==

== PostgreSQL Product News ==

pgpool-II 3.5.1, 3.4.5, 3.3.9, 3.2.14, 3.1.17, and pgpoolAdmin 3.5.1
released. pgpool-II is a connection pooler and replication system for
PostgreSQL.
http://pgpool.net/mediawiki/index.php/Downloads

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

== 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. The CfP is now
open.
http://www.linuxfestnorthwest.org/2016/present

FOSS4G NA, will be held May 2-5, 2016 in Raleigh, North Carolina.
The CfP is still open.
https://2016.foss4g-na.org/cfp

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).
The CfP is open.
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(at)fetter(dot)org, German language
to pwn(at)pgug(dot)de, Italian language to pwn(at)itpug(dot)org(dot) Spanish language
to pwn(at)arpug(dot)com(dot)ar(dot)

== Applied Patches ==

Tom Lane pushed:

- Clean up dubious code in contrib/seg. The restore() function
assumed that the result of sprintf() with %e format would
necessarily contain an 'e', which is false: what if the supplied
number is an infinity or NaN? If that did happen, we'd get a
null-pointer-dereference core dump. The case appears impossible
currently, because seg_in() does not accept such values, and there
are no seg-creating functions that would create one. But it seems
unwise to rely on it never happening in future. Quite aside from
that, the code was pretty ugly: it relied on modifying a static
format string when it could use a "*" precision argument, and it
used strtok() entirely gratuitously, and it stripped off trailing
spaces by hand instead of just not asking for them to begin with.
Coverity noticed the potential null pointer dereference (though I
wonder why it didn't complain years ago, since this code is
ancient). Since this is just code cleanup and forestalling a
hypothetical future bug, there seems no need for back-patching.
http://git.postgresql.org/pg/commitdiff/a75a418d07bf852dc9fdb85ccfb39c763aa057a9

- Fix latent portability issue in pgwin32_dispatch_queued_signals().
The first iteration of the signal-checking loop would compute
sigmask(0) which expands to 1<<(-1) which is undefined behavior
according to the C standard. The lack of field reports of trouble
suggest that it evaluates to 0 on all existing Windows compilers,
but that's hardly something to rely on. Since signal 0 isn't a
queueable signal anyway, we can just make the loop iterate from 1
instead, and save a few cycles as well as avoiding the undefined
behavior. In passing, avoid evaluating the volatile expression
UNBLOCKED_SIGNAL_QUEUE twice in a row; there's no reason to waste
cycles like that. Noted by Aleksander Alekseev, though this isn't
his proposed fix. Back-patch to all supported branches.
http://git.postgresql.org/pg/commitdiff/58666ed28ab59a2686ee08bc648b4e9959aacfce

- Introduce a LOG_SERVER_ONLY ereport level, which is never sent to
client. This elevel is useful for logging audit messages and
similar information that should not be passed to the client. It's
equivalent to LOG in terms of decisions about logging priority in
the postmaster log, but messages with this elevel will never be sent
to the client. In the current implementation, it's just an alias
for the longstanding COMMERROR elevel (or more accurately, we've
made COMMERROR an alias for this). At some point it might be
interesting to allow a LOG_ONLY flag to be attached to any elevel,
but that would be considerably more complicated, and it's not clear
there's enough use-cases to justify the extra work. For now, let's
just take the easy 90% solution. David Steele, reviewed by Fabien
Coelho, Petr Jelínek, and myself
http://git.postgresql.org/pg/commitdiff/66229ac0040cf1e0f5b9d72271aa9feaf3b3a37e

- Add a \gexec command to psql for evaluation of computed queries.
\gexec executes the just-entered query, like \g, but instead of
printing the results it takes each field as a SQL command to send to
the server. Computing a series of queries to be executed is a
fairly common thing, but up to now you always had to resort to
kluges like writing the queries to a file and then inputting the
file. Now it can be done with no intermediate step. The
implementation is fairly straightforward except for its interaction
with FETCH_COUNT. ExecQueryUsingCursor isn't capable of being
called recursively, and even if it were, its need to create a
transaction block interferes unpleasantly with the desired behavior
of \gexec after a failure of a generated query (i.e., that it can
continue). Therefore, disable use of ExecQueryUsingCursor when
doing the master \gexec query. We can still apply it to individual
generated queries, however, and there might be some value in doing
so. While testing this feature's interaction with single-step mode,
I (tgl) was led to conclude that SendQuery needs to recognize SIGINT
(cancel_pressed) as a negative response to the single-step prompt.
Perhaps that's a back-patchable bug fix, but for now I just included
it here. Corey Huinker, reviewed by Jim Nasby, Daniel Vérité, and
myself
http://git.postgresql.org/pg/commitdiff/2bbe9112aec60abc2d3b4c39e75d0cbdcaaa45e1

- Add a few comments about ANALYZE's strategy for collecting MCVs.
Alex Shulgin complained that the underlying strategy wasn't all that
apparent, particularly not the fact that we intentionally have two
code paths depending on whether we think the column has a limited
set of possible values or not. Try to make it clearer.
http://git.postgresql.org/pg/commitdiff/3c69b33f459f62fe6db66c386ef12620ea697f74

- Partially revert commit 3d3bf62f30200500637b24fdb7b992a99f9704c3.
On reflection, the pre-existing logic in ANALYZE is specifically
meant to compare the frequency of a candidate MCV against the
estimated frequency of a random distinct value across the whole
table. The change to compare it against the average frequency of
values actually seen in the sample doesn't seem very principled, and
if anything it would make us less likely not more likely to consider
a value an MCV. So revert that, but keep the aspect of considering
only nonnull values, which definitely is correct. In passing,
rename the local variables in these stanzas to "ndistinct_table", to
avoid confusion with the "ndistinct" that appears at an outer scope
in compute_scalar_stats.
http://git.postgresql.org/pg/commitdiff/391159e03a8b69dd04a1432ceb800c7c4c3d608c

- Disallow newlines in parameter values to be set in ALTER SYSTEM. As
noted by Julian Schauder in bug #14063, the configuration-file
parser doesn't support embedded newlines in string literals. While
there might someday be a good reason to remove that restriction,
there doesn't seem to be one right now. However, ALTER SYSTEM SET
could accept strings containing newlines, since many of the
variable-specific value-checking routines would just see a newline
as whitespace. This led to writing a postgresql.auto.conf file that
was broken and had to be removed manually. Pending a reason to work
harder, just throw an error if someone tries this. In passing, fix
several places in the ALTER SYSTEM logic that failed to provide an
errcode() for an ereport(), and thus would falsely log the failure
as an internal XX000 error. Back-patch to 9.4 where ALTER SYSTEM
was introduced.
http://git.postgresql.org/pg/commitdiff/99f3b5613bd1f145b5dbbe86000337bbe37fb094

- Fix PL/Python for recursion and interleaved set-returning functions.
PL/Python failed if a PL/Python function was invoked recursively via
SPI, since arguments are passed to the function in its global
dictionary (a horrible decision that's far too ancient to undo) and
it would delete those dictionary entries on function exit, leaving
the outer recursion level(s) without any arguments. Not deleting
them would be little better, since the outer levels would then see
the innermost level's arguments. Since PL/Python uses ValuePerCall
mode for evaluating set-returning functions, it's possible for
multiple executions of the same SRF to be interleaved within a
query. PL/Python failed in such a case, because it stored only one
iterator per function, directly in the function's PLyProcedure
struct. Moreover, one interleaved instance of the SRF would see
argument values that should belong to another. Hence, invent code
for saving and restoring the argument entries. To fix the recursion
case, we only need to save at recursive entry and restore at
recursive exit, so the overhead in non-recursive cases is
negligible. To fix the SRF case, we have to save when suspending a
SRF and restore when resuming it, which is potentially not
negligible; but fortunately this is mostly a matter of manipulating
Python object refcounts and should not involve much physical data
copying. Also, store the Python iterator and saved argument values
in a structure associated with the SRF call site rather than the
function itself. This requires adding a memory context deletion
callback to ensure that the SRF state is cleaned up if the calling
query exits before running the SRF to completion. Without that we'd
leak a refcount to the iterator object in such a case, resulting in
session-lifespan memory leakage. (In the pre-existing code, there
was no memory leak because there was only one iterator pointer, but
what would happen is that the previous iterator would be resumed by
the next query attempting to use the SRF. Hardly the semantics we
want.) We can buy back some of whatever overhead we've added by
getting rid of PLy_function_delete_args(), which seems a useless
activity: there is no need to delete argument entries from the
global dictionary on exit, since the next time anyone would see the
global dict is on the next fresh call of the PL/Python function, at
which time we'd overwrite those entries with new arg values anyway.
Also clean up some really ugly coding in the SRF implementation,
including such gems as returning directly out of a PG_TRY block.
(The only reason that failed to crash hard was that all existing
call sites immediately exited their own PG_TRY blocks, popping the
dangling longjmp pointer before there was any chance of it being
used.) In principle this is a bug fix; but it seems a bit too
invasive relative to its value for a back-patch, and besides the fix
depends on memory context callbacks so it could not go back further
than 9.5 anyway. Alexey Grishchenko and Tom Lane
http://git.postgresql.org/pg/commitdiff/1d2fe56e42640613781fc17ab1534fd0551de9bd

- Run pgindent on a batch of (mostly-planner-related) source files.
Getting annoyed at the amount of unrelated chatter I get from
pgindent'ing Rowley's unique-joins patch. Re-indent all the files
it touches.
http://git.postgresql.org/pg/commitdiff/de94e2af184e25576b13cbda8cf825118835d1cd

- Refactor join_is_removable() to separate out distinctness-proving
logic. Extracted from pending unique-join patch, since this is a
rather large delta but it's simply moving code out into
separately-accessible subroutines. I (tgl) did choose to add a bit
more logic to rel_supports_distinctness, so that it verifies that
there's at least one potentially usable unique index rather than
just checking indexlist != NIL. Otherwise there's no functional
change here. David Rowley
http://git.postgresql.org/pg/commitdiff/f338dd7585cab45da9053e883ad65a440a99d3be

- Fix multiple bugs in tablespace symlink removal. Don't try to
examine S_ISLNK(st.st_mode) after a failed lstat(). It's undefined.
Also, if the lstat() reported ENOENT, we do not wish that to be a
hard error, but the code might nonetheless treat it as one (giving
an entirely misleading error message, too) depending on
luck-of-the-draw as to what S_ISLNK() returned. Don't throw error
for ENOENT from rmdir(), either. (We're not really expecting ENOENT
because we just stat'd the file successfully; but if we're going to
allow ENOENT in the symlink code path, surely the directory code
path should too.) Generate an appropriate errcode for
its-the-wrong-type-of-file complaints. (ERRCODE_SYSTEM_ERROR
doesn't seem appropriate, and failing to write errcode() around it
certainly doesn't work, and not writing an errcode at all is not per
project policy.) Valgrind noticed the undefined S_ISLNK result; the
other problems emerged while reading the code in the area. All of
this appears to have been introduced in 8f15f74a44f68f9c.
Back-patch to 9.5 where that commit appeared.
http://git.postgresql.org/pg/commitdiff/93c301fc4ff7d4f06bff98fea8db47ce67f28155

- Add BSD authentication method. Create a "bsd" auth method that
works the same as "password" so far as clients are concerned, but
calls the BSD Authentication service to check the password. This is
currently only available on OpenBSD. Marisa Emerson, reviewed by
Thomas Munro
http://git.postgresql.org/pg/commitdiff/34c33a1f00259ce5e3e1d1b4a784037adfca6057

- Fix unstable regression test output. Output order from the
pg_indexes view might vary depending on the phase of the moon, so
add ORDER BY to ensure stable results of tests added by commit
386e3d7609c49505e079c40c65919d99feb82505. Per buildfarm.
http://git.postgresql.org/pg/commitdiff/690c543550b0d2852060c18d270cdb534d339d9a

- Run pgindent on generic_xlog.c. This code desperately needs some
micro-optimization, and I'd like it to be formatted a bit more
nicely while I work on it.
http://git.postgresql.org/pg/commitdiff/2dd318d277b8e1d8269b030f545240193943162f

- Code review/prettification for generic_xlog.c. Improve commentary,
use more specific names for the delta fields, const-ify pointer
arguments where possible, avoid assuming that initializing only the
first element of a local array will guarantee that the remaining
elements end up as we need them. (I think that code in generic_redo
actually worked, but only because InvalidBuffer is zero; this is a
particularly ugly way of depending on that ...)
http://git.postgresql.org/pg/commitdiff/db03cf375d602e417eda6b7a55eead91618e1398

- Get rid of blinsert()'s use of GenericXLogUnregister(). That
routine is dangerous, and unnecessary once we get rid of this one
caller. In passing, fix failure to clean up temp memory context, or
switch back to caller's context, during slowest exit path.
http://git.postgresql.org/pg/commitdiff/80cf18910c8edf2575c306dde9ead192bdb0863a

- Get rid of GenericXLogUnregister(). This routine is unsafe as
implemented, because it invalidates the page image pointers returned
by previous GenericXLogRegister() calls. Rather than complicate the
API or the implementation to avoid that, let's just get rid of it;
the use-case for having it seems much too thin to justify a lot of
work here. While at it, do some wordsmithing on the SGML docs for
generic WAL.
http://git.postgresql.org/pg/commitdiff/08e785436f84f8824149a2182b0cb9ce2c28e31d

- Fix PL/Python ereport() test to work on Python 2.3. Per buildfarm.
Pavel Stehule
http://git.postgresql.org/pg/commitdiff/c7a141a9866b8c15d9e3b6fd5310e54837900394

- Micro-optimize GenericXLogFinish(). Make the inner comparison loops
of computeDelta() as tight as possible by pulling considerations of
valid and invalid ranges out of the inner loops, and extending a
match or non-match detection as far as possible before deciding what
to do next. To keep this tractable, give up the possibility of
merging fragments across the pd_lower to pd_upper gap. The fraction
of pages where that could happen (ie, there are 4 or fewer bytes in
the gap, *and* data changes immediately adjacent to it on both
sides) is too small to be worth spending cycles on. Also, avoid two
BLCKSZ-length memcpy()s by computing the delta before moving data
into the target buffer, instead of after. This doesn't save nearly
as many cycles as being tenser about computeDelta(), but it still
seems worth doing. On my machine, this patch cuts a full 40% off
the runtime of contrib/bloom's regression test.
http://git.postgresql.org/pg/commitdiff/68689c66efcda6f217119432edfbdf95a50b26e2

- Further minor improvement in generic_xlog.c: always say
REGBUF_STANDARD. Since we're requiring pages handled by
generic_xlog.c to be standard format, specify REGBUF_STANDARD when
doing a full-page image, so that xloginsert.c can compress out the
"hole" between pd_lower and pd_upper. Given the current API in
which this path will be taken only for a newly initialized page, the
hole is likely to be particularly large in such cases, so that this
oversight could easily be performance-significant. I don't notice
any particular change in the runtime of contrib/bloom's regression
test, though.
http://git.postgresql.org/pg/commitdiff/660d5fb856c61df2de2cedb26249404ffc58cb89

- Improve contrib/bloom regression test using code coverage info.
Originally, this test created a 100000-row test table, which made it
run rather slowly compared to other contrib tests. Investigation
with gcov showed that we got no further improvement in code coverage
after the first 700 or so rows, making the large table 99% a waste
of time. Cut it back to 2000 rows to fix the runtime problem and
still leave some headroom for testing behaviors that may appear
later. A closer look at the gcov results showed that the main
coverage omissions in contrib/bloom occurred because the test never
filled more than one entry in the notFullPage array; which is
unsurprising because it exercised index cleanup only in the scenario
of complete table deletion, allowing every page in the index to
become deleted rather than not-full. Add testing that allows the
not-full path to be exercised as well. Also, test the amvalidate
function, because blvalidate.c had zero coverage without that, and
besides it's a good idea to check for mistakes in the bloom opclass
definitions.
http://git.postgresql.org/pg/commitdiff/cf223c3bf5ba16232147c66b5fef4037aafe747c

- Fix access-to-already-freed-memory issue in plpython's error
handling. PLy_elog() could attempt to access strings that Python
had already freed, because the strings that PLy_get_spi_error_data()
returns are simply pointers into storage associated with the error
"val" PyObject. That's fine at the instant PLy_get_spi_error_data()
returns them, but just after that PLy_traceback() intentionally
releases the only refcount on that object, allowing it to be freed
--- so that the strings we pass to ereport() are dangling pointers.
In principle this could result in garbage output or a coredump. In
practice, I think the risk is pretty low, because there are no
Python operations between where we decrement that refcount and where
we use the strings (and copy them into PG storage), and thus no
reason for Python to recycle the storage. Still, it's clearly
hazardous, and it leads to Valgrind complaints when running under a
Valgrind that hasn't been lobotomized to ignore Python memory
allocations. The code was a mess anyway: we fetched the error data
out of Python (clearing Python's error indicator) with PyErr_Fetch,
examined it, pushed it back into Python with PyErr_Restore
(re-setting the error indicator), then immediately pulled it back
out with another PyErr_Fetch. Just to confuse matters even more,
there were some gratuitous-and-yet-hazardous PyErr_Clear calls in
the "examine" step, and we didn't get around to doing
PyErr_NormalizeException until after the second PyErr_Fetch, making
it even less clear which object was being manipulated where and
whether we still had a refcount on it. (If PyErr_NormalizeException
did substitute a different "val" object, it's possible that the
problem could manifest for real, because then we'd be doing assorted
Python stuff with no refcount on the object we have string pointers
into.) So, rearrange all that into some semblance of sanity, and
don't decrement the refcount on the Python error objects until the
end of PLy_elog(). In HEAD, I failed to resist the temptation to
reformat some messy bits from 5c3c3cd0a3046339 along the way.
Back-patch as far as 9.2, because the code is substantially the same
that far back. I believe that 9.1 has the bug as well; but the code
around it is rather different and I don't want to take a chance on
breaking something for what seems a low-probability problem.
http://git.postgresql.org/pg/commitdiff/7e3bb080387f4143cdc908bf97daf9a8abdc445f

- Clean up foreign-key caching code in planner. Coverity complained
that the code added by 015e88942aa50f0d lacked an error check for
SearchSysCache1 failures, which it should have. But the code was
pretty duff in other ways too, including failure to think about
whether it could really cope with arrays of different lengths.
http://git.postgresql.org/pg/commitdiff/5306df2831ab012d8008691f833457bc299962aa

- pg_dump: add missing "destroyPQExpBuffer(query)" in
dumpForeignServer(). Coverity complained about this resource leak
(why now, I don't know, since it's been like that a long time). Our
general policy in pg_dump is that PQExpBuffers are worth cleaning
up, so do it here too. But don't bother with a back-patch, because
it seems unlikely that very many databases contain enough FOREIGN
SERVER objects to notice.
http://git.postgresql.org/pg/commitdiff/074050f16a2db9b5ebe5c9f8fdb211cbb810e746

- Add comment about intentional fallthrough in switch. Coverity
complained about an apparent missing "break" in a switch added by
bb140506df605fab. The human-readable comments are pretty clear that
this is intentional, but add a standard /* FALL THRU */ comment to
make it clear to tools too.
http://git.postgresql.org/pg/commitdiff/1630f5b92a3a00aff5674f31af1d418628a00ac7

- Fix poorly thought-through code from commit 5c3c3cd0a3046339. It's
not entirely clear to me whether PyString_AsString can return null
(looks like the answer might vary between Python 2 and 3). But in
any case, this code's attempt to cope with the possibility was quite
broken, because pstrdup() neither allows a null argument nor ever
returns a null. Moreover, the code below this point assumes that
"message" is a palloc'd string, which would not be the case for a
dgettext result. Fix both problems by doing the pstrdup step
separately.
http://git.postgresql.org/pg/commitdiff/f73b2bbbdcb387aa90ff619fe03d1924ed82b868

Dean Rasheed pushed:

- Improve estimate of distinct values in estimate_num_groups(). When
adjusting the estimate for the number of distinct values from a rel
in a grouped query to take into account the selectivity of the rel's
restrictions, use a formula that is less likely to produce
under-estimates. The old formula simply multiplied the number of
distinct values in the rel by the restriction selectivity, which
would be correct if the restrictions were fully correlated with the
grouping expressions, but can produce significant under-estimates in
cases where they are not well correlated. The new formula is based
on the random selection probability, and so assumes that the
restrictions are not correlated with the grouping expressions. This
is guaranteed to produce larger estimates, and of course risks
over-estimating in cases where the restrictions are correlated, but
that has less severe consequences than under-estimating, which might
lead to a HashAgg that consumes an excessive amount of memory. This
could possibly be improved upon in the future by identifying
correlated restrictions and using a hybrid of the old and new
formulae. Author: Tomas Vondra, with some hacking be me
Reviewed-by: Mark Dilger, Alexander Korotkov, Dean Rasheed and Tom
Lane Discussion:
http://www.postgresql.org/message-id/flat/56CD0381(dot)5060502(at)2ndquadrant(dot)com
http://git.postgresql.org/pg/commitdiff/84f9a35e398f863c62440d3f82fc57b4fedc5d08

Teodor Sigaev pushed:

- Fix typo. Michael Paquier
http://git.postgresql.org/pg/commitdiff/eb7308d29875df773b5b52b06ed3d8b60f1b8242

- fix typo. Andreas Ulbrich
http://git.postgresql.org/pg/commitdiff/9b27aebe7124210c1b0dbacac657edfefa16a006

- Add jsonb_insert. It inserts a new value into an jsonb array at
arbitrary position or a new key to jsonb object. Author: Dmitry
Dolgov Reviewers: Petr Jelinek, Vitaly Burovoy, Andrew Dunstan
http://git.postgresql.org/pg/commitdiff/0b62fd036e1ac48a8432bb9664b21e1f036c1b08

- Make testing of phraseto_tsquery independ from value of
default_text_search_config variable. Per skink buldfarm member
http://git.postgresql.org/pg/commitdiff/a7ace3b6d96c7a1539ed0700865d320258a12f73

- Zeroing unused parts ducring tsquery construction. Per
investigation failure skink buildfarm member and
RANDOMIZE_ALLOCATED_MEMORY help
http://git.postgresql.org/pg/commitdiff/3308467905aa157139d24375850cfe49ee90a0cf

- Rename comparePos() to compareWordEntryPos(). Rename comparePos()
to compareWordEntryPos() to prevent export of too generic name. Per
gripe from Tom Lane.
http://git.postgresql.org/pg/commitdiff/4e55b3f0335c2aa658cd9d1fda4dea2a1f9ab80d

- Phrase full text search. Patch introduces new text search operator
(<-> or <DISTANCE>) into tsquery. On-disk and binary in/out format
of tsquery are backward compatible. It has two side effect: change
order for tsquery, so, users, who has a btree index over tsquery,
should reindex it, less number of parenthesis in tsquery output, and
tsquery becomes more readable Authors: Teodor Sigaev, Oleg Bartunov,
Dmitry Ivanov Reviewers: Alexander Korotkov, Artur Zakirov
http://git.postgresql.org/pg/commitdiff/bb140506df605fab58f48926ee1db1f80bdafb59

- Enhanced custom error in PLPythonu. Patch adds a new, more rich,
way to emit error message or exception from PL/Pythonu code.
Author: Pavel Stehule Reviewers: Catalin Iacob, Peter Eisentraut,
Jim Nasby
http://git.postgresql.org/pg/commitdiff/5c3c3cd0a3046339597a03bc708cb5530dc07059

- Restore original tsquery operation numbering. As noticed by Tom
Lane changing operation's number in commit
bb140506df605fab58f48926ee1db1f80bdafb59 causes on-disk format
incompatibility. Revert to previous numbering, that is reason to
add special array to store priorities of operation. Also it reverts
order of tsquery to previous. Author: Dmitry Ivanov
http://git.postgresql.org/pg/commitdiff/1ec4c7c055ca045c5df6352a4cdacd9aa778e598

- Fix output of regression test of contrib/tsearch2. Just forget to
add in 1ec4c7c055ca045c5df6352a4cdacd9aa778e598
http://git.postgresql.org/pg/commitdiff/38627f687823eae57e932c3b234656342403e909

- Fix possible use of uninitialised value in ts_headline() Found
during investigation of failure of skink buildfarm member and its
valgrind report. Backpatch to all supported branches
http://git.postgresql.org/pg/commitdiff/cb0c8cbf316f9362c11d7a8356e6f459258ae78e

- Revert CREATE INDEX ... INCLUDING ... It's not ready yet, revert
two commits 690c543550b0d2852060c18d270cdb534d339d9a - unstable test
output 386e3d7609c49505e079c40c65919d99feb82505 - patch itself
http://git.postgresql.org/pg/commitdiff/8b99edefcab1e82c43139a2c7dc06d31fb27b3e4

- CREATE INDEX ... INCLUDING (column[, ...]). Now indexes (but only
B-tree for now) can contain "extra" column(s) which doesn't
participate in index structure, they are just stored in leaf tuples.
It allows to use index only scan by using single index instead of
two or more indexes. Author: Anastasia Lubennikova with minor
editorializing by me Reviewers: David Rowley, Peter Geoghegan, Jeff
Janes
http://git.postgresql.org/pg/commitdiff/386e3d7609c49505e079c40c65919d99feb82505

Álvaro Herrera pushed:

- Silence compiler warning. Reported by Peter Eisentraut to occur on
32bit systems
http://git.postgresql.org/pg/commitdiff/c9ff752a854b687fc0a05fd4aba1066028ec5495

- Display WAL pointer in rm_redo error callback. This makes it easier
to identify the source of a recovery problem in case of a bug or
data corruption.
http://git.postgresql.org/pg/commitdiff/890614d2b35bd20468352043870edc7f24a7b8ec

- Support ALTER THING .. DEPENDS ON EXTENSION. This introduces a new
dependency type which marks an object as depending on an extension,
such that if the extension is dropped, the object automatically goes
away; and also, if the database is dumped, the object is included in
the dump output. Currently the grammar supports this for indexes,
triggers, materialized views and functions only, although the
utility code is generic so adding support for more object types is a
matter of touching the parser rules only. Author: Abhijit Menon-Sen
Reviewed-by: Alexander Korotkov, Álvaro Herrera Discussion:
http://www.postgresql.org/message-id/20160115062649.GA5068@toroid.org
http://git.postgresql.org/pg/commitdiff/f2fcad27d59c8e5c48f8fa0a96c8355e40f24273

- Fix broken ALTER INDEX documentation. Commit b8a91d9d1c put the
description of the new IF EXISTS clause in the wrong place -- move
it where it belongs. Backpatch to 9.2.
http://git.postgresql.org/pg/commitdiff/2143f5e127903cb50c10537fc22392083cb033b7

- Support \crosstabview in psql. \crosstabview is a completely
different way to display results from a query: instead of a vertical
display of rows, the data values are placed in a grid where the
column and row headers come from the data itself, similar to a
spreadsheet. The sort order of the horizontal header can be
specified by using another column in the query, and the vertical
header determines its ordering from the order in which they appear
in the query. This only allows displaying a single value in each
cell. If more than one value correspond to the same cell, an error
is thrown. Merging of values can be done in the query itself, if
necessary. This may be revisited in the future. Author: Daniel
Verité Reviewed-by: Pavel Stehule, Dean Rasheed
http://git.postgresql.org/pg/commitdiff/c09b18f21c52cbcf8718d6c267c84fcfea3739a9

- Move \crosstabview regression tests to a separate file. It cannot
run in the same parallel group as misc, because it creates a table
which is unpredictably visible in that test. Per buildfarm member
crake.
http://git.postgresql.org/pg/commitdiff/1ff3f420d470fae46759e948a20e9550af012816

- Fix possible NULL dereference in ExecAlterObjectDependsStmt. I used
the wrong variable here. Doesn't make a difference today because
the only plausible caller passes a non-NULL variable, but someday it
will be wrong, and even today's correctness is subtle: the caller
that does pass a NULL is never invoked because of object type
constraints. Surely not a condition to rely on. Noted by Coverity
http://git.postgresql.org/pg/commitdiff/bd905a0d0416628b4aef153463c1f5e5b80b3e96

Peter Eisentraut pushed:

- Fix error message from wal_level value renaming found by Ian
Barwick.
http://git.postgresql.org/pg/commitdiff/4dcd4da98c786c48b0dbf129c8f7ea592c34a185

- pg_dump: Add table qualifications to some tags. Some object types
have names that are only unique for one table. But for those we
generally didn't put the table name into the dump TOC tag. So it
was impossible to identify these objects if the same name was used
for multiple tables. This affects policies, column defaults,
constraints, triggers, and rules. Fix by adding the table name to
the TOC tag, so that it now reads "$schema $table $object".
Reviewed-by: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/3b3fcc4eeaeecff315420833975e7c87d760bfe1

- Set PAM_RHOST item for PAM authentication. The PAM_RHOST item is
set to the remote IP address or host name and can be used by PAM
modules. A pg_hba.conf option is provided to choose between IP
address and resolved host name. From: Grzegorz Sampolski
<grzsmp(at)gmail(dot)com> Reviewed-by: Haribabu Kommi
<kommi(dot)haribabu(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/2f1d2b7a75fecad25295cb3f453503eb6a176d4f

- Fix printf format.
http://git.postgresql.org/pg/commitdiff/8b737f90843157706b8b5eb401b2aff08da77781

- Replace printf format %i by %d. see also
ce8d7bb6440710058503d213b2aafcdf56a5b481
http://git.postgresql.org/pg/commitdiff/339025c68f95d3cb2c42478109cafeaf414c7fe0

- Distrust external OpenSSL clients; clear err queue. OpenSSL has an
unfortunate tendency to mix per-session state error handling with
per-thread error handling. This can cause problems when programs
that link to libpq with OpenSSL enabled have some other use of
OpenSSL; without care, one caller of OpenSSL may cause problems for
the other caller. Backend code might similarly be affected, for
example when a third party extension independently uses OpenSSL
without taking the appropriate precautions. To fix, don't trust
other users of OpenSSL to clear the per-thread error queue.
Instead, clear the entire per-thread queue ahead of certain I/O
operations when it appears that there might be trouble (these I/O
operations mostly need to call SSL_get_error() to check for success,
which relies on the queue being empty). This is slightly
aggressive, but it's pretty clear that the other callers have a very
dubious claim to ownership of the per-thread queue. Do this is both
frontend and backend code. Finally, be more careful about clearing
our own error queue, so as to not cause these problems ourself.
It's possibly that control previously did not always reach
SSLerrmessage(), where ERR_get_error() was supposed to be called to
clear the queue's earliest code. Make sure ERR_get_error() is
always called, so as to spare other users of OpenSSL the possibility
of similar problems caused by libpq (as opposed to problems caused
by a third party OpenSSL library like PHP's OpenSSL extension).
Again, do this is both frontend and backend code. See bug #12799
and https://bugs.php.net/bug.php?id=68276 Based on patches by Dave
Vitek and Peter Eisentraut. From: Peter Geoghegan <pg(at)bowt(dot)ie>
http://git.postgresql.org/pg/commitdiff/7c7d4fddab82dc756d8caa67b1b31fcdde355aab

Magnus Hagander pushed:

- Fix typo. Etsuro Fujita
http://git.postgresql.org/pg/commitdiff/9457b591b949d3c256dd91043df71fb11657227a

- Implement backup API functions for non-exclusive backups.
Previously non-exclusive backups had to be done using the
replication protocol and pg_basebackup. With this commit it's now
possible to make them using pg_start_backup/pg_stop_backup as well,
as long as the backup program can maintain a persistent connection
to the database. Doing this, backup_label and tablespace_map are
returned as results from pg_stop_backup() instead of being written
to the data directory. This makes the server safe from a crash
during an ongoing backup, which can be a problem with exclusive
backups. The old syntax of the functions remain and work exactly as
before, but since the new syntax is safer this should eventually be
deprecated and removed. Only reference documentation is included.
The main section on backup still needs to be rewritten to cover
this, but since that is already scheduled for a separate large
rewrite, it's not included in this patch. Reviewed by David Steele
and Amit Kapila
http://git.postgresql.org/pg/commitdiff/7117685461af50f50c03f43e6a622284c8d54694

- Add authentication parameters compat_realm and upn_usename for SSPI.
These parameters are available for SSPI authentication only, to make
it possible to make it behave more like "normal gssapi", while
making it possible to maintain compatibility. compat_realm is on by
default, but can be turned off to make the authentication use the
full Kerberos realm instead of the NetBIOS name. upn_username is
off by default, and can be turned on to return the users Kerberos
UPN rather than the SAM-compatible name (a user in Active Directory
can have both a legacy SAM-compatible username and a new Kerberos
one. Normally they are the same, but not always) Author: Christian
Ullrich Reviewed by: Robbie Harwood, Alvaro Herrera, me
http://git.postgresql.org/pg/commitdiff/35e2e357cb054dc9e5d890fe754c56f0722f015e

Robert Haas pushed:

- Add parallel query support functions for assorted aggregates. This
lets us use parallel aggregate for a variety of useful cases that
didn't work before, like sum(int8), sum(numeric), several versions
of avg(), and various other functions. Add some regression tests,
as well, testing the general sanity of these and future catalog
entries. David Rowley, reviewed by Tomas Vondra, with a few further
changes by me.
http://git.postgresql.org/pg/commitdiff/11c8669c0cc7abc7a7702594cf13452c378d2517

- Align all shared memory allocations to cache line boundaries.
Experimentation shows this only costs about 6kB, which seems well
worth it given the major performance effects that can be caused by
insufficient alignment, especially on larger systems. Discussion:
14166(dot)1458924422(at)sss(dot)pgh(dot)pa(dot)us
http://git.postgresql.org/pg/commitdiff/09adc9a8c09c9640de05c7023b27fb83c761e91c

- Fix parallel-safety code for parallel aggregation.
has_parallel_hazard() was ignoring the proparallel markings for
aggregates, which is no good. Fix that. There was no way to mark
an aggregate as actually being parallel-safe, either, so add a
PARALLEL option to CREATE AGGREGATE. Patch by me, reviewed by David
Rowley.
http://git.postgresql.org/pg/commitdiff/41ea0c23761ca108e2f08f6e3151e3cb1f9652a1

- Extend relations multiple blocks at a time to improve scalability.
Contention on the relation extension lock can become quite fierce
when multiple processes are inserting data into the same relation at
the same time at a high rate. Experimentation shows the extending
the relation multiple blocks at a time improves scalability. Dilip
Kumar, reviewed by Petr Jelinek, Amit Kapila, and me.
http://git.postgresql.org/pg/commitdiff/719c84c1be51f3d3fe6049b77ddbaa0c4b58a9a9

- Attempt to fix breakage due to declaration following code. Per Tom
Lane and the buildfarm.
http://git.postgresql.org/pg/commitdiff/b0b64f65054e6b858b845b46298a624aaaea1deb

- Use quicksort, not replacement selection, for external sorting. We
still use replacement selection for the first run of the sort only
and only when the number of tuples is relatively small. Otherwise,
the first run, and subsequent runs in all cases, are produced using
quicksort. This tends to be faster except perhaps for very small
amounts of working memory. Peter Geoghegan, reviewed by Tomas
Vondra, Jeff Janes, Mithun Cy, Greg Stark, and me.
http://git.postgresql.org/pg/commitdiff/0711803775a37e0bf39d7efdd1e34d9d7e640ea1

- Add a 'parallel_degree' reloption. The code that estimates what
parallel degree should be uesd for the scan of a relation is
currently rather stupid, so add a parallel_degree reloption that can
be used to override the planner's rather limited judgement. Julien
Rouhaud, reviewed by David Rowley, James Sewell, Amit Kapila, and
me. Some further hacking by me.
http://git.postgresql.org/pg/commitdiff/25fe8b5f1ac93c3ec01519854e4f554b2e57a926

- Document which aggregates support partial mode. David Rowley,
reviewed by Tomas Vondra
http://git.postgresql.org/pg/commitdiff/752b948dfca23ca8229d4490adc1d54be41c09a3

- Add combine functions for various floating-point aggregates. This
allows parallel aggregation to use them. It may seem surprising
that we use float8_combine for both float4_accum and float8_accum
transition functions, but that's because those functions differ only
in the type of the non-transition-state argument. Haribabu Kommi,
reviewed by David Rowley and Tomas Vondra
http://git.postgresql.org/pg/commitdiff/af025eed536d3842d085ed9e4f9107eb976575cc

Fujii Masao pushed:

- Support multiple synchronous standby servers. Previously
synchronous replication offered only the ability to confirm that all
changes made by a transaction had been transferred to at most one
synchronous standby server. This commit extends synchronous
replication so that it supports multiple synchronous standby
servers. It enables users to consider one or more standby servers as
synchronous, and increase the level of transaction durability by
ensuring that transaction commits wait for replies from all of those
synchronous standbys. Multiple synchronous standby servers are
configured in synchronous_standby_names which is extended to support
new syntax of 'num_sync ( standby_name [ , ... ] )', where num_sync
specifies the number of synchronous standbys that transaction
commits need to wait for replies from and standby_name is the name
of a standby server. The syntax of 'standby_name [ , ... ]' which
was used in 9.5 or before is also still supported. It's the same as
new syntax with num_sync=1. This commit doesn't include "quorum
commit" feature which was discussed in pgsql-hackers. Synchronous
standbys are chosen based on their priorities.
synchronous_standby_names determines the priority of each standby
for being chosen as a synchronous standby. The standbys whose names
appear earlier in the list are given higher priority and will be
considered as synchronous. Other standby servers appearing later in
this list represent potential synchronous standbys. The regression
test for multiple synchronous standbys is not included in this
commit. It should come later. Authors: Sawada Masahiko, Beena
Emerson, Michael Paquier, Fujii Masao Reviewed-By: Kyotaro
Horiguchi, Amit Kapila, Robert Haas, Simon Riggs, Amit Langote,
Thomas Munro, Sameer Thakur, Suraj Kharage, Abhijit Menon-Sen,
Rajeev Rastogi Many thanks to the various individuals who were
involved in discussing and developing this feature.
http://git.postgresql.org/pg/commitdiff/989be0810dffd08b54e1caecec0677608211c339

- Use proper format specifier %X/%X for LSN, again. Commit cee31f5
fixed this problem, but commit 989be08 accidentally reverted the
fix. Thomas Munro
http://git.postgresql.org/pg/commitdiff/ead9963c471ccde50ff220e8294ea11a57eee91c

- Fix a couple of places in doc that implied there was only one sync
standby. Thomas Munro
http://git.postgresql.org/pg/commitdiff/8643b91ecf8f47a1307df4a00d66b2fceada0d6f

- Add regression tests for multiple synchronous standbys. Authors:
Suraj Kharage, Michael Paquier, Masahiko Sawada, refactored by me
Reviewed-By: Kyotaro Horiguchi
http://git.postgresql.org/pg/commitdiff/196b72fb9a5556c66f2b012cc4e869175a3049fa

Simon Riggs pushed:

- Revert bf08f2292ffca14fd133aa0901d1563b6ecd6894. Remove recent
changes to logging XLOG_RUNNING_XACTS by request.
http://git.postgresql.org/pg/commitdiff/cac0e36682970ec1276d3da3d3ee37325544a2bb

- Avoid archiving XLOG_RUNNING_XACTS on idle server. If
archive_timeout > 0 we should avoid logging XLOG_RUNNING_XACTS if
idle. Bug 13685 reported by Laurence Rowe, investigated in detail
by Michael Paquier, though this is not his proposed fix.
20151016203031(dot)3019(dot)72930(at)wrigleys(dot)postgresql(dot)org Simple
non-invasive patch to allow later backpatch to 9.4 and 9.5
http://git.postgresql.org/pg/commitdiff/bf08f2292ffca14fd133aa0901d1563b6ecd6894

- Modify test_decoding/messages to remove non-ascii chars
http://git.postgresql.org/pg/commitdiff/d25379eb23383f1d2f969e65e0332b47c19aea94

- Generic Messages for Logical Decoding. API and mechanism to allow
generic messages to be inserted into WAL that are intended to be
read by logical decoding plugins. This commit adds an optional new
callback to the logical decoding API. Messages are either text or
bytea. Messages can be transactional, or not, and are identified by
a prefix to allow multiple concurrent decoding plugins. (Not to be
confused with Generic WAL records, which are intended to allow crash
recovery of extensible objects.) Author: Petr Jelinek and Andres
Freund Reviewers: Artur Zakirov, Tomas Vondra, Simon Riggs
Discussion: 5685F999(dot)6010202(at)2ndquadrant(dot)com
http://git.postgresql.org/pg/commitdiff/3fe3511d05127cc024b221040db2eeb352e7d716

- Load FK defs into relcache for use by planner. Fastpath ignores
this if no triggers defined. Author: Tomas Vondra, with fastpath
and comments added by me Reviewers: David Rowley, Simon Riggs
http://git.postgresql.org/pg/commitdiff/015e88942aa50f0d419ddac00e63bb06d6e62e86

- Use Foreign Key relationships to infer multi-column join
selectivity. In cases where joins use multiple columns we currently
assess each join separately causing gross mis-estimates for join
cardinality. This patch adds use of FK information for the first
time into the planner. When FKs are present and we have multi-column
join information, plan estimates will be drastically improved. Cases
with multiple FKs are handled, though partial matches are ignored
currently. Net effect is substantial performance improvements for
joins in many common cases. Additional planning time is isolated to
cases that are currently performing poorly, measured at 0.08 - 0.15
ms. Please watch for planner performance regressions; circumstances
seem unlikely but the law of unintended consequences may apply
somewhen. Additional complex tests welcome to prove this before
release. Tests can be performed using SET enable_fkey_estimates =
on | off using scripts provided during Hackers discussions, message
id: 552335D9(dot)3090707(at)2ndquadrant(dot)com Authors: Tomas Vondra and David
Rowley Reviewed and tested by Simon Riggs, adding comments only
http://git.postgresql.org/pg/commitdiff/137805f89acb361144ec98d9847e26d2848aa57e

Stephen Frost pushed:

- Add new catalog called pg_init_privs. This new catalog holds the
privileges which the system was initialized with at initdb time,
along with any permissions set by extensions at CREATE EXTENSION
time. This allows pg_dump (and any other similar use-cases) to
detect when the privileges set on initdb-created or
extension-created objects have been changed from what they were set
to at initdb/extension-creation time and handle those changes
appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
http://git.postgresql.org/pg/commitdiff/6c268df1276e9dd73e4d2cc89cf8787e8f186bda

- In pg_dump, use a bitmap to represent what to include. pg_dump has
historically used a simple boolean 'dump' value to indicate if a
given object should be included in the dump or not. Instead, use a
bitmap which breaks down the components of an object into their
distinct pieces and use that bitmap to only include the components
requested. This does not include any behavioral change, but is in
preperation for the change to dump out just ACLs for objects in
pg_catalog. Reviews by Alexander Korotkov, Jose Luis Tallon
http://git.postgresql.org/pg/commitdiff/a9f0e8e5a2e779a888988cb64479a6723f668c84

- In pg_dump, include pg_catalog and extension ACLs, if changed. Now
that all of the infrastructure exists, add in the ability to dump
out the ACLs of the objects inside of pg_catalog or the ACLs for
objects which are members of extensions, but only if they have been
changed from their original values. The original values are tracked
in pg_init_privs. When pg_dump'ing 9.6-and-above databases, we will
dump out the ACLs for all objects in pg_catalog and the ACLs for all
extension members, where the ACL has been changed from the original
value which was set during either initdb or CREATE EXTENSION. This
should not change dumps against pre-9.6 databases. Reviews by
Alexander Korotkov, Jose Luis Tallon
http://git.postgresql.org/pg/commitdiff/23f34fa4ba358671adab16773e79c17c92cbc870

- In pg_dump, split "dump" into "dump" and "dump_contains".
Historically, the "dump" component of the namespace has been used to
decide if the objects inside of the namespace should be dumped also.
Given that "dump" is now a bitmask and may be partial, and we may
want to dump out all components of the namespace object but only
some of the components of objects contained in the namespace, create
a "dump_contains" bitmask which will represent what components of
the objects inside of a namespace should be dumped out. No behavior
change here, but in preparation for a change where we will dump out
just the ACLs of objects in pg_catalog, but we might not dump out
the ACL of the pg_catalog namespace itself (for instance, when it
hasn't been changed from the value set at initdb time). Reviews by
Alexander Korotkov, Jose Luis Tallon
http://git.postgresql.org/pg/commitdiff/d217b2c360cb9a746b4ef122c568bdfedb6d726e

- Bump catversion for pg_dump dump catalog ACL patches. Pointed out
by Tom.
http://git.postgresql.org/pg/commitdiff/29dd1504a12f324c75f6b5ce8863505e499633ec

- Use GRANT system to manage access to sensitive functions. Now that
pg_dump will properly dump out any ACL changes made to functions
which exist in pg_catalog, switch to using the GRANT system to
manage access to those functions. This means removing 'if
(!superuser()) ereport()' checks from the functions themselves and
then REVOKEing EXECUTE right from 'public' for these functions in
system_views.sql. Reviews by Alexander Korotkov, Jose Luis Tallon
http://git.postgresql.org/pg/commitdiff/1574783b4ced0356fbc626af1a1a469faa6b41e1

- GRANT rights to CURRENT_USER instead of adding roles. We shouldn't
be adding roles during the regression tests as that can cause
back-to-back installcheck runs to fail and users running the
regression tests likley don't want those extra roles. Pointed out
by Tom
http://git.postgresql.org/pg/commitdiff/6928484bda454f9ab2456d385b2d317f18b6bf1a

- In dumpTable, re-instate the skipping logic. Pretty sure I removed
this based on some incorrect thinking that it was no longer possible
to reach this point for a table which will not be dumped, but that's
clearly wrong. Pointed out on IRC by Erik Rijkers.
http://git.postgresql.org/pg/commitdiff/689f9a058854a1a32e994818dd6d79f49d8f8a1b

- Fix improper usage of 'dump' bitmap. Now that 'dump' is a bitmap,
we can't simply set it to 'true'. Noticed while debugging the prior
issue.
http://git.postgresql.org/pg/commitdiff/fa6075e5515c6878b2c1fe1c6435dd7ed847857d

- Create default roles. This creates an initial set of default roles
which administrators may use to grant access to, historically,
superuser-only functions. Using these roles instead of granting
superuser access reduces the number of superuser roles required for
a system. Documention for each of the default roles has been added
to user-manag.sgml. Bump catversion to 201604082, as we had a
commit that bumped it to 201604081 and another that set it back to
201604071... Reviews by José Luis Tallón and Robert Haas
http://git.postgresql.org/pg/commitdiff/7a542700df25eaf97b794bff63606176433dcdda

- Reserve the "pg_" namespace for roles. This will prevent users from
creating roles which begin with "pg_" and will check for those roles
before allowing an upgrade using pg_upgrade. This will allow for
default roles to be provided at initdb time. Reviews by José Luis
Tallón and Robert Haas
http://git.postgresql.org/pg/commitdiff/293007898d3fa5a815c1c5814df53627553f114d

Noah Misch pushed:

- Standardize GetTokenInformation() error reporting. Commit
c22650cd6450854e1a75064b698d7dcbb4a8821a sparked a discussion about
diverse interpretations of "token user" in error messages. Expel
old and new specimens of that phrase by making all
GetTokenInformation() callers report errors the way GetTokenUser()
has been reporting them. These error conditions almost can't
happen, so users are unlikely to observe this change. Reviewed by
Tom Lane and Stephen Frost.
http://git.postgresql.org/pg/commitdiff/f2b1b3079ce9d2965f6e450585f24d18cdf5647b

- Remove redundant message in AddUserToTokenDacl(). GetTokenUser()
will have reported an adequate error message. These error
conditions almost can't happen, so users are unlikely to observe
this change. Reviewed by Tom Lane and Stephen Frost.
http://git.postgresql.org/pg/commitdiff/33d3fc5e2aac32fcf356c09cee4bfded6613a1f3

Kevin Grittner pushed:

- Detect SSI conflicts before reporting constraint violations. While
prior to this patch the user-visible effect on the database of any
set of successfully committed serializable transactions was always
consistent with some one-at-a-time order of execution of those
transactions, the presence of declarative constraints could allow
errors to occur which were not possible in any such ordering, and
developers had no good workarounds to prevent user-facing errors
where they were not necessary or desired. This patch adds a check
for serialization failure ahead of duplicate key checking so that if
a developer explicitly (redundantly) checks for the pre-existing
value they will get the desired serialization failure where the
problem is caused by a concurrent serializable transaction;
otherwise they will get a duplicate key error. While it would be
better if the reads performed by the constraints could count as part
of the work of the transaction for serialization failure checking,
and we will hopefully get there some day, this patch allows a clean
and reliable way for developers to work around the issue. In many
cases existing code will already be doing the right thing for this
to "just work". Author: Thomas Munro, with minor editing of docs by
me Reviewed-by: Marko Tiikkaja, Kevin Grittner
http://git.postgresql.org/pg/commitdiff/fcff8a575198478023ada8a48e13b50f70054766

- Modify BufferGetPage() to prepare for "snapshot too old" feature.
This patch is a no-op patch which is intended to reduce the chances
of failures of omission once the functional part of the "snapshot
too old" patch goes in. It adds parameters for snapshot, relation,
and an enum to specify whether the snapshot age check needs to be
done for the page at this point. This initial patch passes NULL for
the first two new parameters and BGP_NO_SNAPSHOT_TEST for the third.
The follow-on patch will change the places where the test needs to
be made.
http://git.postgresql.org/pg/commitdiff/8b65cf4c5edabdcae45ceaef7b9ac236879aae50

- Add snapshot_too_old to NSVC @contrib_excludes. The buildfarm
showed failure for Windows MSVC builds due to this omission. This
might not be the only problem with the Makefile for this feature,
but hopefully this will get it past the immediate problem. Fix
suggested by Tom Lane
http://git.postgresql.org/pg/commitdiff/279d86afdbed550425bc9d1327ade2dc0028ad33

- Fix typo in C comment.
http://git.postgresql.org/pg/commitdiff/381200be4b565292eba6f62200248cb775f06940

- Turn special page pointer validation to static inline function.
Inclusion of multiple macros inside another macro was pushing MSVC
past its size liimit. Reported by buildfarm.
http://git.postgresql.org/pg/commitdiff/56dffb5a73ab157fc8d35a76c1170d656a051f14

- Add the "snapshot too old" feature. This feature is controlled by a
new old_snapshot_threshold GUC. A value of -1 disables the feature,
and that is the default. The value of 0 is just intended for
testing. Above that it is the number of minutes a snapshot can
reach before pruning and vacuum are allowed to remove dead tuples
which the snapshot would otherwise protect. The xmin associated
with a transaction ID does still protect dead tuples. A connection
which is using an "old" snapshot does not get an error unless it
accesses a page modified recently enough that it might not be able
to produce accurate results. This is similar to the Oracle feature,
and we use the same SQLSTATE and error message for compatibility.
http://git.postgresql.org/pg/commitdiff/848ef42bb8c7909c9d7baa38178d4a209906e7c1

Andres Freund pushed:

- Increase maximum number of clog buffers. Benchmarking has shown
that the current number of clog buffers limits scalability. We've
previously increased the number in 33aaa139, but that's not
sufficient with a large number of clients. We've benchmarked the
cost of increasing the limit by benchmarking worst case scenarios;
testing showed that 128 buffers don't cause a regression, even in
contrived scenarios, whereas 256 does There are a number of more
complex patches flying around to address various clog scalability
problems, but this is simple enough that we can get it into 9.6; and
is beneficial even after those patches have been applied. It is a
bit unsatisfactory to increase this in small steps every few
releases, but a better solution seems to require a rewrite of
slru.c; not something done quickly. Author: Amit Kapila and Andres
Freund Discussion:
CAA4eK1+-=18HOrdqtLXqOMwZDbC_15WTyHiFruz7BvVArZPaAw(at)mail(dot)gmail(dot)com
http://git.postgresql.org/pg/commitdiff/5364b357fb115ed4dc7174085d8f59d9425638dd

- Expose more out/readfuncs support functions. Previously bcac23d
exposed a subset of support functions, namely the ones Kaigai found
useful. In 20160304193704(dot)elq773pyg5fyl3mi(at)alap3(dot)anarazel(dot)de I
mentioned that there's some functions missing to use the facility in
an external project. To avoid having to add functions piecemeal,
add all the functions which are used to define READ_* and WRITE_*
macros; users of the extensible node functionality are likely to
need these. Additionally expose outDatum(), which doesn't have it's
own WRITE_ macro, as it needs information from the embedding struct.
Discussion: 20160304193704(dot)elq773pyg5fyl3mi(at)alap3(dot)anarazel(dot)de
http://git.postgresql.org/pg/commitdiff/c1ddd2361f6eb071d51b856c697a4aab22f8c776

- Avoid the use of a separate spinlock to protect a LWLock's wait
queue. Previously we used a spinlock, in adition to the atomically
manipulated ->state field, to protect the wait queue. But it's
pretty simple to instead perform the locking using a flag in state.
Due to 6150a1b0 BufferDescs, on platforms (like PPC) with > 1 byte
spinlocks, increased their size above 64byte. As 64 bytes are the
size we pad allocated BufferDescs to, this can increase false
sharing; causing performance problems in turn. Together with the
previous commit this reduces the size to <= 64 bytes on all common
platforms. Author: Andres Freund Discussion:
CAA4eK1+ZeB8PMwwktf+3bRS0Pt4Ux6Rs6Aom0uip8c6shJWmyg(at)mail(dot)gmail(dot)com
20160327121858(dot)zrmrjegmji2ymnvr(at)alap3(dot)anarazel(dot)de
http://git.postgresql.org/pg/commitdiff/008608b9d51061b1f598c197477b3dc7be9c4a64

- Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially
in read-mostly cache resident workloads. Benchmarking shows that in
various scenarios the spinlock protecting a buffer header's state
becomes a significant bottleneck. The problem can be reproduced with
pgbench -S on larger machines, but can be considerably worse for
queries which touch the same buffers over and over at a high
frequency (e.g. nested loops over a small inner table). To allow
atomic operations to be used, cram BufferDesc's flags, usage_count,
buf_hdr_lock, refcount into a single 32bit atomic variable; that
allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which
could be lifted by using a 64bit field, but it's not a realistic
configuration atm). As not all operations can easily implemented in
a lockfree manner, implement the previous buf_hdr_lock via a flag
bit in the atomic variable. That way we can continue to lock the
header in places where it's needed, but can get away without
acquiring it in the more frequent hot-paths. There's some
additional operations which can be done without the lock, but aren't
in this patch; but the most important places are covered. As
bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already
two users, and more are coming up; there's a follupw patch for
lwlock.c at least. This patch is based on a proof-of-concept
written by me, which Alexander Korotkov made into a fully working
patch; the committed version is again revised by me. Benchmarking
and testing has, amongst others, been provided by Dilip Kumar,
Alexander Korotkov, Robert Haas. On a large x86 system improvements
for readonly pgbench, with a high client count, of a factor of 8
have been observed. Author: Alexander Korotkov and Andres Freund
Discussion: 2400449(dot)GjM57CE0Yg(at)dinodell
http://git.postgresql.org/pg/commitdiff/48354581a49c30f5757c203415aa8412d85b0f70

Andrew Dunstan pushed:

- Turn down MSVC compiler verbosity. Most of what is produced by the
detailed verbosity level is of no interest at all, so switch to the
normal level for more usable output. Christian Ullrich. Backpatch
to all live branches
http://git.postgresql.org/pg/commitdiff/01a07e6c11562127ad5e6f58d3d6128416b8ab65

- Silence warning from modern perl about unescaped braces
http://git.postgresql.org/pg/commitdiff/76a1c97bf21c301f61bb41345e0cdd0d365b2086

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Kyotaro HORIGUCHI sent in two more revisions of a patch to add tab
completion for IF [NOT] EXISTS to psql.

Emre Hasegeli sent in a patch to change "magick" to "magic."

Artur Zakirov sent in a patch to fix a typo in the documentation of
indexam.

Aleksander Alekseev sent in two revisions of a patch to fix an issue
in how sigmask works.

David Steele sent in two more revisions of a patch to filter messages
including errors that might expose information needlessly.

Fabrízio de Royes Mello sent in two more revisions of a patch to add a
sequence access method.

Amit Langote and Kyotaro HORIGUCHI traded patches to fix an issue
where altering a foreign table was failing to invalidate prepared
statement execution plan that depended on its previous state.

Robbie Harwood sent in another revision of a patch to implement GSSAPI
encryption.

Etsuro Fujita sent in another revision of a patch to handle odd
system-column handling in postgres_fdw join pushdown.

Etsuro Fujita and Rushabh Lathia traded patches to optimize writes to
the postgres fdw.

Rod Taylor sent in a patch to implement LOCK TABLE .. DEFERRABLE.

Craig Ringer sent in a patch to add some tests to pg_xlogdump.

Craig Ringer sent in a patch to fix incorrect comments introduced in
logical decoding timeline following.

Anastasia Lubennikova sent in five more revisions of a patch to add
covering unique indexes.

Pavel Stěhule sent in another revision of a patch to create a RAW
output format for COPY.

Aleksander Alekseev sent in a patch to simplify reorderbuffer.c

Simon Riggs sent in another revision of a patch to avoid archiving
XLOG_RUNNING_XACTS on idle server.

Muhammad Asif Naeem sent in a patch to add an EMERGENCY option to VACUUM
that forces to avoid extend any entries in the VM or FSM.

David Rowley and Tom Lane traded patches to improve performance of
outer joins when the outer side is unique.

Fabien COELHO sent in a patch to allow seeding randomness in pgbench.

WANGSHUO sent in a patch to allow UPDATE to operate on column aliases.

Michaël Paquier sent in another revision of a patch to add support for
VS 2015 in MSVC scripts.

Michaël Paquier sent in a patch to fix parallel pg_dump on Win32.

Aleksander Alekseev sent in a patch to fix an issue in snapmgr.c that
wrongly assumes that subxcnt > 0 iff xcnt > 0.

Anastasia Lubennikova sent in a patch to make the amcheck tool work
with covering unique indexes.

Constantin S. Pan sent in another revision of a patch to speed up GIN
index builds with parallel workers.

Stephen Frost sent in a patch to fix breakage of pg_dump caused by the
covering unique indexes patch.

Stephen Frost sent in a patch to remove superuser checks in
pgstattuple 1.4.

David Fetter sent in two more revisions of a patch to implement
weighted central moments as aggregates.

Stas Kelvich sent in another revision of a patch to speed up 2PC
transactions.

Jeff Janes sent in a patch to add tab completion for ALTER EXTENSION
to psql.

David Rowley sent in a patch to make parallel aggregate costs consider
combine/serial/deserial functions.

Stephen Frost sent in a patch to add regression tests for CREATE
ROLE/USAGE.

Andres Freund sent in a patch to disable pymalloc when running under
valgrind.