== PostgreSQL Weekly News - February 05 2017 ==

== PostgreSQL Weekly News - February 05 2017 ==

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

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

== PostgreSQL Product News ==

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

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

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

== PostgreSQL Jobs for February ==

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

== PostgreSQL Local ==

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

PostgreSQL(at)SCaLE will take place on March 2-3, 2017, at Pasadena Convention
Center, as part of SCaLE 15X.
http://www.socallinuxexpo.org/scale/15x/

PgConf.Russia 2017 will take place on 15-17 March 2017 in Moscow.
https://pgconf.ru/en

PGDay Asia 2017 will be held March 17-18 in Singapore.
http://tinyurl.com/pgDay-Asia-2017-Cfp

Nordic PGDay 2017 will be held in Stockholm, Sweden, at the Sheraton
Hotel, on March 21, 2017.
https://2017.nordicpgday.org/

pgDay Paris 2017 will be held in Paris, France on March 23, 2017.
http://2017.pgday.paris/

PGConf US 2017 CfP will be on March 28-31 in Jersey City, New Jersey.
http://www.pgconf.us/2017/

PGCon 2017 will take place in Ottawa on 23-26 May.
http://www.pgcon.org/2017/papers.php

== PostgreSQL in the News ==

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

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

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

== Applied Patches ==

Stephen Frost pushed:

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

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

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

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

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

Heikki Linnakangas pushed:

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

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

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

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

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

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

Tom Lane pushed:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Peter Eisentraut pushed:

- Additional test coverage for sequences. Reviewed-by: Michael Paquier
<michael(dot)paquier(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/d711532b2eb70cf2f56d95efcc608d474266d769

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

- doc: Document result set of CREATE_REPLICATION_SLOT. From: Marko Tiikkaja
<marko(at)joh(dot)to>
http://git.postgresql.org/pg/commitdiff/ecb814b5cef4971e50ee177eff320d416aa0b882

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

Álvaro Herrera pushed:

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

Robert Haas pushed:

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

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

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

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

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

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

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

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

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

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

Andrew Dunstan pushed:

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

Noah Misch pushed:

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

Fujii Masao pushed:

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

== Pending Patches ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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