== PostgreSQL Weekly News - January 17 2016 ==

== PostgreSQL Weekly News - January 17 2016 ==

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/

== PostgreSQL Product News ==

cstore_fdw 1.4, a columnar store extension for PostgreSQL, released.
https://www.citusdata.com/blog/14-marco/355-cstore-fdw-1.4-released

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

Ora2PG 16.2, a migration system for moving from Oracle and MySQL to
PostgreSQL, released.
http://ora2pg.darold.net/

pgBadger 7.2, a parallel PostgreSQL log analyzer written in Perl, released:
http://dalibo.github.io/pgbadger/
Development:
https://github.com/dalibo/pgbadger/

PipelineDB Enterprise, a relational streaming-SQL database based on
PostgreSQL, released.
https://www.pipelinedb.com/enterprise

== PostgreSQL Jobs for January ==

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

== PostgreSQL Local ==

PostgreSQL(at)SCaLE is a two day, two track event which takes place on Jan.
21-22, 2016, at Pasadena Convention Center, as part of SCaLE 14X.
https://www.socallinuxexpo.org/scale/14x/cfp

FOSDEM PGDay is a one day conference that will be held ahead of FOSDEM in
Brussels, Belgium, on Jan 29th, 2016. Registration is still open.
http://fosdem2016.pgconf.eu/

Prague PostgreSQL Developer Day 2016 (P2D2 2016) is a two-day conference
that will be held on February 17-18 2016 in Prague, Czech Republic.
Czech language web site below:
http://www.p2d2.cz/

The annual Indian PGday will be held in Bengaluru, Karnataka, India on
February 26, 2016.
http://pgday.in

The first pan-Asian PostgreSQL conference will be held March 16-17,
2016 in Singapore.
http://2016.pgday.asia/

Nordic PGDay 2016 is a one day one track conference which will be held in
Helsinki, Finland, on March 17, 2016. Registration is still open.
http://2016.nordicpgday.org/

PGConf US 2016 will take place April 18-20, 2016 in NYC. The CfP is
open until January 31st, 2016, 11:59pm EST.
http://www.pgconf.us/2016/

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

PGCon 2016 will be held May 17-21, 2016 in Ottawa. The CfP is still open.
http://www.pgcon.org/

== PostgreSQL in the News ==

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

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

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

== Applied Patches ==

Peter Eisentraut pushed:

- doc: Fix typo in logical decoding documentation. From: Petr Jelinek
<petr(at)2ndquadrant(dot)com>
http://git.postgresql.org/pg/commitdiff/c618e1b5067d4a8233f8f403a87fd168fb621a39

- psql: Improve CREATE INDEX CONCURRENTLY tab completion. The
completion of CREATE INDEX CONCURRENTLY was lacking in several ways
compared to a plain CREATE INDEX command: - CREATE INDEX <name> ON
completes table names, but didn't with CONCURRENTLY. - CREATE INDEX
completes ON and existing index names, but with CONCURRENTLY it only
completed ON. - CREATE INDEX <name> completes ON, but didn't with
CONCURRENTLY. These are now all fixed.
http://git.postgresql.org/pg/commitdiff/b1bfb28b586a319052d96dd4dfd40a05505ea6ed

- psql: Fix CREATE INDEX tab completion. The previous code supported
a syntax like CREATE INDEX name CONCURRENTLY, which never existed.
Mistake introduced in commit
37ec19a15ce452ee94f32ebc3d6a9a45868e82fd. Remove the addition of
CONCURRENTLY at that point.
http://git.postgresql.org/pg/commitdiff/bc56d5898d1cbd9dee6fe16ea7a814a5820b6181

- psql: Update tab completion comment This just updates a comment to
match the code. from Michael Paquier
http://git.postgresql.org/pg/commitdiff/70327030095d07abb58f9b3452dc6315a02aff0e

- psql: Add completion support for DROP INDEX CONCURRENTLY based on
patch by Kyotaro Horiguchi
http://git.postgresql.org/pg/commitdiff/4189e3d659abb48d159a6c3faabaa7e99498ca3e

Robert Haas pushed:

- Remove obsolete comment. Noted while reviewing a question from
Dickson S. Guedes.
http://git.postgresql.org/pg/commitdiff/950ab82c3d967e6f4cec2a7c8ead2edd5b311518

- Fix spelling mistakes. Same patch submitted independently by David
Rowley and Peter Geoghegan.
http://git.postgresql.org/pg/commitdiff/23c2dd03d5db2f4a20dcd09bd6c49e293e3c8f03

Tom Lane pushed:

- Avoid dump/reload problems when using both plpython2 and plpython3.
Commit 803716013dc1350f installed a safeguard against loading
plpython2 and plpython3 at the same time, but asserted that both
could still be used in the same database, just not in the same
session. However, that's not actually all that practical because
dumping and reloading will fail (since both libraries necessarily
get loaded into the restoring session). pg_upgrade is even worse,
because it checks for missing libraries by loading every .so library
mentioned in the entire installation into one session, so that you
can have only one across the whole cluster. We can improve matters
by not throwing the error immediately in _PG_init, but only when and
if we're asked to do something that requires calling into libpython.
This ameliorates both of the above situations, since while execution
of CREATE LANGUAGE, CREATE FUNCTION, etc will result in loading
plpython, it isn't asked to do anything interesting (at least not if
check_function_bodies is off, as it will be during a restore). It's
possible that this opens some corner-case holes in which a crash
could be provoked with sufficient effort. However, since plpython
only exists as an untrusted language, any such crash would require
superuser privileges, making it "don't do that" not a security
issue. To reduce the hazards in this area, the error is still FATAL
when it does get thrown. Per a report from Paul Jones. Back-patch
to 9.2, which is as far back as the patch applies without work. (It
could be made to work in 9.1, but given the lack of previous
complaints, I'm disinclined to expend effort so far back. We've
been pretty desultory about support for Python 3 in 9.1 anyway.)
http://git.postgresql.org/pg/commitdiff/866566a690bb9916dcd294807e65a6e173396530

- Use LOAD not actual code execution to pull in plpython library.
Commit 866566a690bb9916 is insufficient to prevent dump/reload
failures when using transform modules in a database with both
plpython2 and plpython3 installed. The reason is that the transform
extension scripts use DO blocks as a mechanism to pull in the
libpython library before creating the transform function. It's
necessary to preload the library because the dynamic loader won't do
it for us on every platform, leading to "unresolved symbol" failures
when the transform library is loaded. But it's *not* necessary to
execute Python code, and doing so will provoke a
multiple-Pythons-are-loaded error even after the preceding commit.
To fix, use LOAD instead of a DO block. That requires superuser
privilege, but creation of a C function does anyway. It also embeds
knowledge of the underlying library name for each PL language; but
that's wired into the initdb-time contents of pg_pltemplate too, so
that doesn't seem like a large problem either. Note that CREATE
TRANSFORM as such doesn't call the language module at all. Per a
report from Paul Jones. Back-patch to 9.5 where transform modules
were introduced.
http://git.postgresql.org/pg/commitdiff/fb6fcbd33fbbd6d31fa2b39938e60ecb48dc4de4

- Remove no-longer-needed old-style check for incompatible plpythons.
Commit 866566a690bb9916 introduced a new mechanism for incompatible
plpythons to detect each other. I left the old mechanism in place,
because it seems possible that a plpython predating that commit
might be used with one postdating it. (This would require updating
plpython3 but not plpython2 or vice versa, but that seems well
within the realm of possibility.) However, surely it will not be
able to happen in 9.6 or later, so we can delete the old mechanism
in HEAD.
http://git.postgresql.org/pg/commitdiff/796d1e889f2b5f88b33a425fdfd08d7906cbd66a

- Run pgindent on src/bin/pg_dump/* To ease doing indent fixups on a
couple of patches I have in progress.
http://git.postgresql.org/pg/commitdiff/26905e009babe6020fddcf3820e57e2f87c5539c

- Access pg_dump's options structs through Archive struct, not
directly. Rather than passing around DumpOptions and RestoreOptions
as separate arguments, add fields to struct Archive to carry
pointers to these objects, and access them through those fields when
needed. There already was a RestoreOptions pointer in Archive,
though for no obvious reason it was part of the "private" struct
rather than out where pg_dump.c could see it. Doing this allows
reversion of quite a lot of parameter-addition changes made in
commit 0eea8047bf, which is a good thing IMO because this will
reduce the code delta between 9.4 and 9.5, probably easing a few
future back-patch efforts. Moreover, the previous commit only added
a DumpOptions argument to functions that had to have it at the time,
which means we could anticipate still more code churn (and more
back-patch hazard) as the requirement spread further. I'd hit
exactly that problem in my upcoming patch to fix extension
membership marking, which is what motivated me to do this.
http://git.postgresql.org/pg/commitdiff/5b5fea2a11741e651f7c25e981dd29b610a08426

- Handle extension members when first setting object dump flags in
pg_dump. pg_dump's original approach to handling extension member
objects was to run around and clear (or set) their dump flags rather
late in its data collection process. Unfortunately, quite a lot of
code expects those flags to be valid before that; which was an
entirely reasonable expectation before we added extensions. In
particular, this explains Karsten Hilbert's recent report of
pg_upgrade failing on a database in which an extension has been
installed into the pg_catalog schema. Its objects are initially
marked as not-to-be-dumped on the strength of their schema, and
later we change them to must-dump because we're doing a binary
upgrade of their extension; but we've already skipped essential
tasks like making associated DO_SHELL_TYPE objects. To fix, collect
extension membership data first, and incorporate it in the initial
setting of the dump flags, so that those are once again correct from
the get-go. This has the undesirable side effect of slightly
lengthening the time taken before pg_dump acquires table locks, but
testing suggests that the increase in that window is not very much.
Along the way, get rid of ugly special-case logic for deciding
whether to dump procedural languages, FDWs, and foreign servers;
dump decisions for those are now correct up-front, too. In 9.3 and
up, this also fixes erroneous logic about when to dump event
triggers (basically, they were *always* dumped before). In 9.5 and
up, transform objects had that problem too. Since this problem came
in with extensions, back-patch to all supported versions.
http://git.postgresql.org/pg/commitdiff/e72d7d85310c397a94748db72d73a59c57e0b0dc

- Fix build_grouping_chain() to not clobber its input lists. There's
no good reason for stomping on the input data; it makes the logic in
this function no simpler, in fact probably the reverse. And it
makes it impossible to separate path generation from plan
generation, as I'm working towards doing; that will require more
than one traversal of these lists.
http://git.postgresql.org/pg/commitdiff/a923af382c5678f3dfb591aacb6b90bf4e5ed7a9

- Remove dead code in pg_dump. Coverity quite reasonably complained
that this check for fout==NULL occurred after we'd already
dereferenced fout. However, the check is just dead code since there
is no code path by which CreateArchive can return a null pointer.
Errors such as can't-open-that-file are reported down inside
CreateArchive, and control doesn't return. So let's silence the
warning by removing the dead code, rather than continuing to pretend
it does something. Coverity didn't complain about this before
5b5fea2a1, so back-patch to 9.5 like that patch.
http://git.postgresql.org/pg/commitdiff/57ce9acc04483df4913921d4ff21f01483583fb8

Simon Riggs pushed:

- Maintain local LogwrtResult consistently Teach GetFlushRecPtr() to
update LogwrtResult cache as performed by all other functions in
xlog.c
http://git.postgresql.org/pg/commitdiff/1e29e6324ca7d52eb751c8d63881d1f7c44e3921

- Add new user fn pg_current_xlog_flush_location() Tomas Vondra,
reviewed by Michael Paquier and Amit Kapila Minor edits by me
http://git.postgresql.org/pg/commitdiff/e63bb4549a2f47b86de9fc21c9f8b00440f34f99

Magnus Hagander pushed:

- Properly close token in sspi authentication. We can never leak more
than one token, but we shouldn't do that. We don't bother closing it
in the error paths since the process will exit shortly anyway.
Christian Ullrich
http://git.postgresql.org/pg/commitdiff/6a61d1ff9dce7406c0affdc013da27ed4252ba29

- Fix minor typo in comment Tatsuro Yamada
http://git.postgresql.org/pg/commitdiff/cf7dfbf2d6c5892747cd6fca399350d86c16f00f

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Simon Riggs sent in another revision of a patch to speed up 2PC.

Marisa Emerson sent in another revision of a patch to support BSD
Authentication.

Elvis Pranskevichus sent in a patch to fix an issue with dumping
domain constraints in pg_dump.

Michael Paquier and Fabien COELHO traded patches to extend pgbench
expressions with functions.

Dilip Kumar sent in another revision of a patch to help make relation
extension more scalable.

Etsuro Fujita sent in another revision of a patch to help make FDW DML
pushdown more efficient.

SAWADA Masahiko sent in two more revisions of a patch to add a
"frozen" bit to the visibility map.

Anastasia Lubennikova sent in two more revisions of a patch to
implement covering unique indexes.

Amit Kapila sent in a patch to optimize parallelism code for launched
workers usage.

Michael Paquier sent in a patch to remove the service-related code in
pg_ctl for Cygwin.

Tom Lane sent in a patch to show what might be needed to fix
PL/Python[23] issues in PostgreSQL 9.1. In view of 9.1's short
remaining life, this is not going to be applied.

David Rowley sent in two more revisions of a patch to remove
functionally dependent GROUP BY columns.

Filip Rembiałkowski sent in a patch to document the fact that
BYPASSRLS is a CREATE USER option.

Andres Freund sent in a patch to allow to easily choose between the
readiness primitives in unix_latch.c, error out if waiting on socket
readiness without a specified socket, only clear unix_latch.c's
self-pipe if it actually contains data, and support using epoll as the
polling primitive in unix_latch.c.

Amit Langote sent in a patch to fix a comment thinko in
expand_inherited_rtentry().

Vinayak Pokale sent in a patch to fix a typo in sequence.c.

Tatsuro Yamada sent in a patch to fix a comment typo in
port/atomics/generic.h.

David Rowley sent in two more revisions of a patch to implement
combining aggregates.

Mithun C Y sent in a patch to cache snapshot data avoid cuncurrent
write to cache.

Etsuro Fujita sent in another revision of a patch to create foreign
scan plan.

Etsuro Fujita sent in a patch to update a comment in setrefs.c.

Etsuro Fujita sent in a patch to make a minor documentation tweak to
GetForeignPlan documentation.

Alexander Shulgin sent in a POC patch to create
pg_logical_slot_stream_relation.

Christian Ullrich sent in another revision of a patch to fix an error
in SSPI auth that could cause the wrong realm name to be used.

Jeff Janes sent in another revision of a patch to expose the GIN
clean pending list to SQL.

Constantin S. Pan sent in a patch to speed up GIN build with parallel
workers.

Andreas Seltenreich sent in a patch to improve spinlock inline
assembly for x86.

José Arthur Benetasso Villanova sent in a patch to log operating
system user connecting via unix socket.

Dean Rasheed sent in another revision of a patch to implement
trigonometric functions in degrees.