== PostgreSQL Weekly News - April 17 2016 ==

From: David Fetter <david(at)fetter(dot)org>
To: PostgreSQL Announce <pgsql-announce(at)postgresql(dot)org>
Subject: == PostgreSQL Weekly News - April 17 2016 ==
Date: 2016-04-17 21:44:01
Message-ID: 20160417214401.GB7788@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-announce

== PostgreSQL Weekly News - April 17 2016 ==

PostgreSQL Session will be held on September 22th, 2016, in Lyon,
France. The submission deadline is May 20, 2016. Send proposals to
call-for-paper AT postgresql-sessions DOT org.

== PostgreSQL Product News ==

Amazon RDS for PostgreSQL now supports major version 9.5.
https://aws.amazon.com/about-aws/whats-new/2016/04/rds-postgresql-9-5-support/

== 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.
http://www.linuxfestnorthwest.org/2016/

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

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

Fujii Masao pushed:

- Use ereport(ERROR) instead of Assert() to emit syncrep_parser error.
The existing code would either Assert or generate an invalid
SyncRepConfig variable, neither of which is desirable. A regular
error should be thrown instead. This commit silences compiler
warning in non assertion-enabled builds. Per report from Jeff
Janes. Suggested fix by Tom Lane.
http://git.postgresql.org/pg/commitdiff/0038c1e2181b520a9307aae6587e110468072392

- Remove unused function GetOldestWALSendPointer from walsender code.
That unused function was introduced as a sample because synchronous
replication or replication monitoring tools might need it in the
future. Recently commit 989be08 added the function
SyncRepGetOldestSyncRecPtr which provides almost the same
functionality for multiple synchronous standbys feature. So it's
time to remove that unused sample function. This commit does that.
Branch ------ master Details -------
http://git.postgresql.org/pg/commitdiff/46d73e0d65eef19e25bb0d31f1e5c23ff40a3444
http://git.postgresql.org/pg/commitdiff/cfe96ae24c97ff376157c48ccd5ca6d3938632be

- Fix duplicated index entry in doc. Commit cfe96ae corrected the
name of pg_logical_emit_message() in its index entry. But this typo
fix caused duplicated index entry because there was another index
entry for the function. Spotted by Tom Lane.
http://git.postgresql.org/pg/commitdiff/c8cb7453233b31a177b08a3b2bdac4c31508dc00

- Make regression test for multiple synchronous standbys more stable.
The regression test checks whether the output of pg_stat_replication
is expected or not after changing synchronous_standby_names and
reloading the configuration file. Regarding this test logic,
previously there was a timing issue which made the test result
unstable. That is, pg_stat_replication could return unexpected
result during small window after the configuration file was reloaded
before new setting value took effect, and which made the test fail.
This commit changes the test logic so that it uses a loop with a
timeout to give some room for the test to pass. Now the test fails
only when pg_stat_replication keeps returning unexpected result for
30 seconds. Michael Paquier
http://git.postgresql.org/pg/commitdiff/36c1c91604cee164c6487afb99508f7ff8737b96

Peter Eisentraut pushed:

- cpluspluscheck: Update include path. Some things in
src/include/fe_utils require libpq headers, so add libpq's include
path to the command line used here.
http://git.postgresql.org/pg/commitdiff/ee5dbc8173d8f434a467380bfd218ef6f91a8e31

- Add directory created during build to gitignore.
http://git.postgresql.org/pg/commitdiff/29ca231b83a142ea1633e7c496619accb7dd9e4f

- Fix whitespace.
http://git.postgresql.org/pg/commitdiff/d8ed83cd7fd1082f60a5b9897b62216f6b3e2587

- Fix whitespace.
http://git.postgresql.org/pg/commitdiff/70715e6a600f1652a04b4e698dad3c7d6bff6bdb

- psql: Add new gettext trigger.
http://git.postgresql.org/pg/commitdiff/c3136876734b31ce50018f39c87b00145a8c7c33

- doc: Add missing parentheses. From: Alexander Law
<exclusion(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/d2de44c2ce5c697a2de8089fb377816b2387107a

- doc: Change some "user" to "role" for consistency in the section.
suggested by Johannes Choo
http://git.postgresql.org/pg/commitdiff/5fdda1ceab35311367ed0dbb283cd8aea896e49b

- doc: Markup improvement
http://git.postgresql.org/pg/commitdiff/efb25e56d8a43917bcadfe3904691b1e1cdbbe20

Tom Lane pushed:

- Fix missing "volatile" in PLy_output(). Commit 5c3c3cd0a3046339
plastered "volatile" on a bunch of variables in PLy_output(), but
removed the one that actually mattered, ie the one on "oldcontext".
This allows some versions of clang to generate code in which
"oldcontext" has been trashed when control reaches the PG_CATCH
block. Per buildfarm member tick.
http://git.postgresql.org/pg/commitdiff/81ba9348d85fdf87e84cc02112933b592845bda2

- Fix freshly-introduced PL/Python portability bug. It turns out that
those PyErr_Clear() calls I removed from plpy_elog.c in
7e3bb080387f4143 et al were not quite as random as they appeared:
they mask a Python 2.3.x bug. (Specifically, it turns out that
PyType_Ready() can fail if the error indicator is set on entry, and
PLy_traceback's fetch of frame.f_code may be the first operation in
a session that requires the "frame" type to be readied. Ick.) Put
back the clear call, but in a more centralized place closer to what
it's protecting, and this time with a comment warning what it's
really for. Per buildfarm member prairiedog. Although prairiedog
was only failing on HEAD, it seems clearly possible for this to
occur in older branches as well, so back-patch to 9.2 the same as
the previous patch.
http://git.postgresql.org/pg/commitdiff/1d2f9de38d18152f83cf570581cebac0733ff504

- Fix two places that thought Windows64 is indicated by WIN64 macro.
Everyplace else thinks it's _WIN64, so make these places fall in
line. The pg_regress.c usage is not going to result in any change
in behavior, only suppressing (or not) a compiler warning about
downcasting HANDLEs. So there seems no need for back-patching
there. The libpq/win32.mak usage might represent an actual bug, if
anyone were using this script to build for Windows64, which perhaps
nobody is. Given the lack of field complaints, no back-patch here
either. pg_regress.c problem found by Christian Ullrich, the other
by me.
http://git.postgresql.org/pg/commitdiff/b0e40d189325dc7a54d2546245e766f8c47a7c8d

- Fix _SPI_execute_plan() for CREATE TABLE IF NOT EXISTS foo AS ...
When IF NOT EXISTS was added to CREATE TABLE AS, this logic didn't
get the memo, possibly resulting in an Assert failure. It looks
like there would have been no ill effects in a non-Assert build,
though. Back-patch to 9.5 where the IF NOT EXISTS option was added.
Stas Kelvich
http://git.postgresql.org/pg/commitdiff/39c283e498de1bb7c3d5beadfffcf3273ae8cc27

- Remove unnecessary definition of _WIN64 in libpq/win32.mak. In
commit b0e40d189325dc7a54d2546245e766f8c47a7c8d, I should have just
removed the /D switch defining WIN64. The reason the code worked
before is that all Windows64 compilers automatically predefine
_WIN64. Perhaps at one time we had code that depended on WIN64
being defined, but it's long gone, and we should not encourage any
reappearance. Per discussion with Christian Ullrich.
http://git.postgresql.org/pg/commitdiff/e7bcde8ca0d376d9d23d61855baf67122a66c76a

- In generic WAL application and replay, ensure page "hole" is always
zero. The previous coding could allow the contents of the "hole"
between pd_lower and pd_upper to diverge during replay from what it
had been when the update was originally applied. This would pose a
problem if checksums were in use, and in any case would complicate
forensic comparisons between master and slave servers. So force the
"hole" to contain zeroes, both at initial application of a
generically-logged action, and at replay. Alexander Korotkov,
adjusted slightly by me
http://git.postgresql.org/pg/commitdiff/bdf7db81921deb99fd9d489cbcc635906c89e215

- Improve API of GenericXLogRegister(). Rename this function to
GenericXLogRegisterBuffer() to make it clearer what it does, and
leave room for other sorts of "register" actions in future. Also,
replace its "bool isNew" argument with an integer flags argument, so
as to allow adding more flags in future without an API break.
Alexander Korotkov, adjusted slightly by me
http://git.postgresql.org/pg/commitdiff/5713f03973e26ad6df6df5ac8b9efa0123d68062

- Improve coding of column-name parsing in psql's new crosstabview.c.
Coverity complained about this code, not without reason because it
was rather messy. Adjust it to not scribble on the passed string;
that adds one malloc/free cycle per column name, which is going to
be insignificant in context. We can actually const-ify both the
string argument and the PGresult. Daniel Verité, with some further
cleanup by me
http://git.postgresql.org/pg/commitdiff/7a5f8b5c59033ac153963f98b9109be9529a824a

- Redefine create_upper_paths_hook as being invoked once per upper
relation. Per discussion, this gives potential users of the hook
more flexibility, because they can build custom Paths that implement
only one stage of upper processing atop core-provided Paths for
earlier stages.
http://git.postgresql.org/pg/commitdiff/f1f01de145d0aaca80e6cf8b2ccb7e7f4ed1ad02

- Improve documentation for \crosstabview. Fix misleading syntax
summary (there cannot be a space between colH and scolH). Provide a
link from the existing crosstab() function's documentation to
\crosstabview. Copy-edit the command's description. Christoph Berg
and Tom Lane
http://git.postgresql.org/pg/commitdiff/85e004707715f5ee7a6bfc3d03d0fbc837fb2432

- Fix assorted portability issues with using msync() for data
flushing. Commit 428b1d6b29ca599c5700d4bc4f4ce4c5880369bf
introduced the use of msync() for flushing dirty data from the
kernel's file buffers. Several portability issues were overlooked,
though: * Not all implementations of mmap() think that nbytes == 0
means "map the whole file". To fix, use lseek() to find out the
true length. Fix callers of pg_flush_data to be aware that nbytes
== 0 may result in trashing the file's seek position. * Not all
implementations of mmap() will accept partial-page mmap requests.
To fix, round down the length request to whatever sysconf() says the
page size is. (I think this is OK from a portability standpoint,
because sysconf() is required by SUS v2, and we aren't trying to
compile this part on Windows anyway. Buildfarm should let us know
if not.) * On 32-bit machines, the file size might exceed the
available free address space, or even exceed what will fit in
size_t. Check for the latter explicitly to avoid passing a false
request size to mmap(). If mmap fails, silently fall through to the
next implementation method, rather than bleating to the postmaster
log and giving up. * mmap'ing directories fails on some platforms,
and even if it works, msync'ing the directory is quite unlikely to
help, as for that matter are the other flush implementations. In
pre_sync_fname(), just skip flush attempts on directories. In
passing, copy-edit the comments a bit. Stas Kelvich and myself
http://git.postgresql.org/pg/commitdiff/fa11a09fed2b6f483231608866a682ee3a376277

- Widen amount-to-flush arguments of FileWriteback and callers. It's
silly to define these counts as narrower than they might someday
need to be. Also, I believe that the BLCKSZ * nflush calculation in
mdwriteback was capable of overflowing an int.
http://git.postgresql.org/pg/commitdiff/95ef43c4308102d23afa887c9fc28d9977612a2d

- Fix pg_dump so pg_upgrade'ing an extension with simple opfamilies
works. As reported by Michael Feld, pg_upgrade'ing an installation
having extensions with operator families that contain just a single
operator class failed to reproduce the extension membership of those
operator families. This caused no immediate ill effects, but would
create problems when later trying to do a plain dump and restore,
because the seemingly-not-part-of- the-extension operator families
would appear separately in the pg_dump output, and then would
conflict with the families created by loading the extension. This
has been broken ever since extensions were introduced, and many of
the standard contrib extensions are affected, so it's a bit
astonishing nobody complained before. The cause of the problem is a
perhaps-ill-considered decision to omit such operator families from
pg_dump's output on the grounds that the CREATE OPERATOR CLASS
commands could recreate them, and having explicit CREATE OPERATOR
FAMILY commands would impede loading the dump script into pre-8.3
servers. Whatever the merits of that decision when 8.3 was being
written, it looks like a poor tradeoff now. We can fix the
pg_upgrade problem simply by removing that code, so that the
operator families are dumped explicitly (and then will be properly
made to be part of their extensions). Although this fixes the
behavior of future pg_upgrade runs, it does nothing to clean up
existing installations that may have improperly-linked operator
families. Given the small number of complaints to date, maybe we
don't need to worry about providing an automated solution for that;
anyone who needs to clean it up can do so with manual "ALTER
EXTENSION ADD OPERATOR FAMILY" commands, or even just ignore the
duplicate-opfamily errors they get during a pg_restore. In any case
we need this fix. Back-patch to all supported branches.
Discussion: <20228(dot)1460575691(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/6cead413bb92be0579a2dbf6320121edcc32e369

- Fix broken dependency-mongering for index operator classes/families.
For a long time, opclasscmds.c explained that "we do not create a
dependency link to the AM [for an opclass or opfamily], because we
don't currently support DROP ACCESS METHOD". Commit
473b93287040b200 invented DROP ACCESS METHOD, but it batted only 1
for 2 on adding the dependency links, and 0 for 2 on updating the
comments about the topic. In passing, undo the same commit's
entirely inappropriate decision to blow away an existing index as a
side-effect of create_am.sql.
http://git.postgresql.org/pg/commitdiff/92a30a7eb0cadb008e18053f199af7de3fc1abaa

- Fix prototype of pgwin32_bind(). I (tgl) had copied-and-pasted this
from pgwin32_accept(), failing to notice that the third parameter
should be "int" not "int *". David Rowley
http://git.postgresql.org/pg/commitdiff/22989a8e34168f576e0f90b16fc3edabd28c40e6

- Provide errno-translation wrappers around bind() and listen() on
Windows. I've seen one too many "could not bind IPv4 socket: No
error" log entries from the Windows buildfarm members. Per previous
discussion, this is likely caused by the fact that we're doing
nothing to translate WSAGetLastError() to errno. Put in a wrapper
layer to do that. If this works as expected, it should get
back-patched, but let's see what happens in the buildfarm first.
Discussion: <4065(dot)1452450340(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/d1b7d4877b9a71f476e8e5adea3b6afe419896ba

- Docs: clarify description of LIMIT/OFFSET behavior. Section 7.6 was
a tad confusing because it specified what LIMIT NULL does, but
neglected to do the same for OFFSET NULL, making this look like
perhaps a special case or a wrong restatement of the bit about LIMIT
ALL. Wordsmith a bit while at it. Per bug #14084.
http://git.postgresql.org/pg/commitdiff/fda21aa05bdc96c2c4141f5fd1245a11a41cf62c

- Adjust datatype of ReplicationState.acquired_by. It was declared as
"pid_t", which would be fine except that none of the places that
printed it in error messages took any thought for the possibility
that it's not equivalent to "int". This leads to warnings on some
buildfarm members, and could possibly lead to actually wrong error
messages on those platforms. There doesn't seem to be any very good
reason not to just make it "int"; it's only ever assigned from
MyProcPid, which is int. If we want to cope with PIDs that are
wider than int, this is not the place to start. Also, fix the
comment, which seems to perhaps be a leftover from a time when the
field was only a bool? Per buildfarm. Back-patch to 9.5 which has
same issue.
http://git.postgresql.org/pg/commitdiff/994f11257328e272a6a43d3de59ffa916cbfbe96

- Adjust signature of walrcv_receive hook. Commit 314cbfc5da988eff
redefined the signature of this hook as typedef int
(*walrcv_receive_type) (char **buffer, int *wait_fd); But in fact
the type of the "wait_fd" variable ought to be pgsocket, which is
what WaitLatchOrSocket expects, and which is necessary if we want to
be able to assign PGINVALID_SOCKET to it on Windows. So fix that.
http://git.postgresql.org/pg/commitdiff/c2dc194bdbf5f84ceb433ed416eb389c1234ebc9

- Fix core dump in ReorderBufferRestoreChange on alignment-picky
platforms. When re-reading an update involving both an old tuple
and a new tuple from disk, reorderbuffer.c was careless about
whether the new tuple is suitably aligned for direct access --- in
general, it isn't. We'd missed seeing this in the buildfarm because
the contrib/test_decoding tests exercise this code path only a few
times, and by chance all of those cases have old tuples with length
a multiple of 4, which is usually enough to make the access to the
new tuple's t_len safe. For some still-not-entirely-clear reason,
however, Debian's sparc build gets a bus error, as reported by
Christoph Berg; perhaps it's assuming 8-byte alignment of the
pointer? The lack of previous field reports is probably because you
need all of these conditions to trigger a crash: an alignment-picky
platform (not Intel), a transaction large enough to spill to disk,
an update within that xact that changes a primary-key field and has
an odd-length old tuple, and of course logical decoding tracing the
transaction. Avoid the alignment assumption by using memcpy instead
of fetching t_len directly, and add a test case that exposes the
crash on picky platforms. Back-patch to 9.4 where the bug was
introduced. Discussion: <20160413094117(dot)GC21485(at)msg(dot)credativ(dot)de>
http://git.postgresql.org/pg/commitdiff/6a3d3965d6d5eec30e1c36b3ffa3355ee9201933

- Rethink \crosstabview's argument parsing logic. \crosstabview
interpreted its arguments in an unusual way, including doing
case-insensitive matching of unquoted column names, which is surely
not the right thing. Rip that out in favor of doing something
equivalent to the dequoting/case-folding rules used by other psql
commands. To keep it simple, change the syntax so that the optional
sort column is specified as a separate argument, instead of the
also-quite-unusual syntax that attached it to the colH argument with
a colon. Also, rework the error messages to be closer to project
style.
http://git.postgresql.org/pg/commitdiff/6f0d6a507889d94a79c0d18577a0cb1ccc2b6815

- Fix memory leak in GIN index scans. The code had a query-lifespan
memory leak when encountering GIN entries that have posting lists
(rather than posting trees, ie, there are a relatively small number
of heap tuples containing this index key value). With a suitable
data distribution this could add up to a lot of leakage. Problem
seems to have been introduced by commit 36a35c550, so back-patch to
9.4. Julien Rouhaud
http://git.postgresql.org/pg/commitdiff/f0e766bd7f77774075297526bd2da8f3de226c1f

- Fix portability problem induced by commit a6f6b7819. pg_xlogdump
includes bufmgr.h. With a compiler that emits code for static
inline functions even when they're unreferenced, that leads to
unresolved external references in the new static-inline version of
BufferGetPage(). So hide it with #ifndef FRONTEND, as we've done
for similar issues elsewhere. Per buildfarm member pademelon.
http://git.postgresql.org/pg/commitdiff/6b85d4ba9b09dc94cf1b14aef517da095a83cdbb

- Fix possible crash in ALTER TABLE ... REPLICA IDENTITY USING INDEX.
Careless coding added by commit 07cacba983ef79be could result in a
crash or a bizarre error message if someone tried to select an index
on the OID column as the replica identity index for a table.
Back-patch to 9.4 where the feature was introduced. Discussion:
CAKJS1f8TQYgTRDyF1_u9PVCKWRWz+DkieH=U7954HeHVPJKaKg(at)mail(dot)gmail(dot)com
David Rowley
http://git.postgresql.org/pg/commitdiff/8f1911d5e6d5a1e62c860ddb040d664b01c6415c

- Use less-generic names in matview.sql. The original coding of this
test used table and view names like "t", "tv", "foo", etc. This
tended to interfere with doing simple manual tests in the regression
database; not to mention that it posed a considerable risk of
conflict with other regression test scripts. Prefix these names
with "mvtest_" to avoid such conflicts. Also, change
transiently-created role name to be "regress_xxx" per discussions
about being careful with regression-test role creation.
http://git.postgresql.org/pg/commitdiff/4447f0bcb66547708fa977d6b252046e792a7e04

- Disallow creation of indexes on system columns (except for OID).
Although OID acts pretty much like user data, the other system
columns do not, so an index on one would likely misbehave. And it's
pretty hard to see a use-case for one, anyway. Let's just forbid
the case rather than worry about whether it should be supported.
David Rowley
http://git.postgresql.org/pg/commitdiff/c34df8a003c3e478d70e8251bd2a24d710b297d4

- Adjust spin.c's spinlock emulation so that 0 is not a valid spinlock
value. We've had repeated troubles over the years with failures to
initialize spinlocks correctly; see 6b93fcd14 for a recent example.
Most of the time, on most platforms, such oversights can escape
notice because all-zeroes is the expected initial content of an
slock_t variable. The only platform we have where the initialized
state of an slock_t isn't zeroes is HPPA, and that's practically
gone in the wild. To make it easier to catch such errors without
needing one of those, adjust the --disable-spinlocks code so that
zero is not a valid value for an slock_t for it. In passing, remove
a bunch of unnecessary #include's from spin.c; commit
daa7527afc227443 removed all the intermodule coupling that made them
necessary.
http://git.postgresql.org/pg/commitdiff/4039c736eb0955cb1daf88e211f105dbbb78f7ea

- Avoid code duplication in \crosstabview. In commit 6f0d6a507 I
added a duplicate copy of psqlscanslash's identifier downcasing
code, but actually it's not hard to split that out as a callable
subroutine and avoid the duplication.
http://git.postgresql.org/pg/commitdiff/9603a32594d2f5e6d9a1f098bc554a68f44ccb3c

Stephen Frost pushed:

- Correct copyright for newly added genericdesc.c It's 2016 these days
(no, not entirely sure how we got here either). Pointed out by Amit
Langote
http://git.postgresql.org/pg/commitdiff/cd13471f2e9dee6d411cae3ddae72d0ad6b58c4d

- Disallow SET SESSION AUTHORIZATION pg_* As part of reserving the
pg_* namespace for default roles and in line with SET ROLE and other
previous efforts, disallow settings the role to a default/reserved
role using SET SESSION AUTHORIZATION. These checks and restrictions
on what is allowed regarding default / reserved roles are under
debate, but it seems prudent to ensure that the existing checks at
least cover the intended cases while the debate rages on. On me to
clean it up if the consensus decision is to remove these checks.
http://git.postgresql.org/pg/commitdiff/bfed4ab824789fd7c000286650d4498dccb05634

- In recordExtensionInitPriv(), keep the scan til we're done with it
For reasons of sheer brain fade, we (I) was calling
systable_endscan() immediately after systable_getnext() and
expecting the tuple returned by systable_getnext() to still be
valid. That's clearly wrong. Move the systable_endscan() down
below the tuple usage. Discovered initially by Pavel Stehule and
then also by Alvaro. Add a regression test based on Alvaro's
testing.
http://git.postgresql.org/pg/commitdiff/99f2f3c19ae7d6aa2950a9bdb549217c5a60d941

Kevin Grittner pushed:

- Make oldSnapshotControl a pointer to a volatile structure It was
incorrectly declared as a volatile pointer to a non-volatile
structure. Eliminate the OldSnapshotControl struct definition; it
is really not needed. Pointed out by Tom Lane. While at it, add
OldSnapshotControlData to pgindent's list of structures.
http://git.postgresql.org/pg/commitdiff/80647bf65a03e232c995c0826ef394dad8d685fe

- Use static inline function for BufferGetPage() I was initially
concerned that the some of the hundreds of references to
BufferGetPage() where the literal BGP_NO_SNAPSHOT_TEST were passed
might not optimize as well as a macro, leading to some hard-to-find
performance regressions in corner cases. Inspection of disassembled
code has shown identical code at all inspected locations, and the
size difference doesn't amount to even one byte per such call. So
make it readable. Per gripes from Álvaro Herrera and Tom Lane
http://git.postgresql.org/pg/commitdiff/a6f6b78196a701702ec4ff6df56c346bdcf9abd2

- Avoid extra locks in GetSnapshotData if old_snapshot_threshold < 0
On a big NUMA machine with 1000 connections in saturation load there
was a performance regression due to spinlock contention, for
acquiring values which were never used. Just fill with dummy values
if we're not going to use them. This patch has not been benchmarked
yet on a big NUMA machine, but it seems like a good idea on general
principle, and it seemed to prevent an apparent 2.2% regression on a
single-socket i7 box running 200 connections at saturation load.
http://git.postgresql.org/pg/commitdiff/2201d801b03c2d1b0bce4d6580b718dc34d38b3e

Teodor Sigaev pushed:

- Add page id to bloom index Added to ensure that bloom index pages
can be distinguished from other pages by pg_filedump. Because there
wasn't any public/production versions before, it doesn't pay
attention to any compatibility issues. Per notice from Tom Lane
http://git.postgresql.org/pg/commitdiff/813b456ea21d4cf57b124bf855ec019c7a8099a7

Robert Haas pushed:

- Fix costing for parallel aggregation. The original patch kind of
ignored the fact that we were doing something different from a
costing point of view, but nobody noticed. This patch fixes that
oversight. David Rowley
http://git.postgresql.org/pg/commitdiff/deb71fa9713dfe374a74fc58a5d298b5f25da3f5

- Use PG_INT32_MIN instead of reiterating the constant. Makes no
difference, but it's cleaner this way. Michael Paquier
http://git.postgresql.org/pg/commitdiff/cbb2a812d710dd58e68088b334f8c492346a0d0f

- Tweak EXPLAIN for parallel query to show workers launched. The
previous display was sort of confusing, because it didn't
distinguish between the number of workers that we planned to launch
and the number that actually got launched. This has already
confused several people, so display both numbers and label them
clearly. Julien Rouhaud, reviewed by me.
http://git.postgresql.org/pg/commitdiff/5702277ca97396384eaf5c58d582b79b9984ce73

- postgres_fdw: Clean up handling of system columns. Previously,
querying the xmin column of a single postgres_fdw foreign table
fetched the tuple length, xmax the typmod, and cmin or cmax the
composite type OID of the tuple. However, when you queried several
such tables and the join got shipped to the remote side, these
columns ended up containing the remote values of the corresponding
columns. Both behaviors are rather unprincipled, the former for
obvious reasons and the latter because the remote values of these
columns don't have any local significance; our transaction IDs are
in a different space than those of the remote machine. Clean this
up by setting all of these fields to 0 in both cases. Also fix the
handling of tableoid to be sane. Robert Haas and Ashutosh Bapat,
reviewed by Etsuro Fujita.
http://git.postgresql.org/pg/commitdiff/da7d44b627ba839de32c9409aca659f60324de76

Andres Freund pushed:

- void atomic operation in MarkLocalBufferDirty(). The recent patch
to make Pin/UnpinBuffer lockfree in the hot path (48354581a),
accidentally used pg_atomic_fetch_or_u32() in
MarkLocalBufferDirty(). Other code operating on local buffers was
careful to only use pg_atomic_read/write_u32 which just read/write
from memory; to avoid unnecessary overhead. On its own that'd just
make MarkLocalBufferDirty() slightly less efficient, but in addition
InitLocalBuffers() doesn't call pg_atomic_init_u32() - thus the
spinlock fallback for the atomic operations isn't initialized. That
in turn caused, as reported by Tom, buildfarm animal gaur to fail.
As those errors are actually useful against this type of error,
continue to omit - intentionally this time - initialization of the
atomic variable. In addition, add an explicit note about only using
pg_atomic_read/write on local buffers's state to BufferDesc's
description. Reported-By: Tom Lane Discussion:
1881(dot)1460431476(at)sss(dot)pgh(dot)pa(dot)us
http://git.postgresql.org/pg/commitdiff/6b93fcd149329d4ee7319561b30fc15a573c6307

- Make init_spin_delay() C89 compliant and change stuck spinlock
reporting. The current definition of init_spin_delay (introduced
recently in 48354581a) wasn't C89 compliant. It's not legal to refer
to refer to non-constant expressions, and the ptr argument was one.
This, as reported by Tom, lead to a failure on buildfarm animal
pademelon. The pointer, especially on system systems with ASLR,
isn't super helpful anyway, though. So instead of making
init_spin_delay into an inline function, make s_lock_stuck() report
the function name in addition to file:line and change
init_spin_delay() accordingly. While not a direct replacement, the
function name is likely more useful anyway (line numbers are often
hard to interpret in third party reports). This also fixes what
file/line number is reported for waits via s_lock(). As
PG_FUNCNAME_MACRO is now used outside of elog.h, move it to c.h.
Reported-By: Tom Lane Discussion: 4369(dot)1460435533(at)sss(dot)pgh(dot)pa(dot)us
http://git.postgresql.org/pg/commitdiff/80abbeba23d466b6541cf95082a9e1f36704424e

- Add required database and origin filtering for logical messages.
Logical messages, added in 3fe3511d05, during decoding failed to
filter messages emitted in other databases and messages emitted
"under" a replication origin the output plugin isn't interested in.
Add tests to verify that both types of filtering actually work.
While touching message.sql remove hunk obsoleted by d25379e. Bump
XLOG_PAGE_MAGIC because xl_logical_message changed and because
3fe3511d05 had omitted doing so. 3fe3511d05 additionally didn't bump
catversion, but 7a542700d has done so since. Author: Petr Jelinek
Reported-By: Andres Freund Discussion:
20160406142513(dot)wotqy3ba3kanr423(at)alap3(dot)anarazel(dot)de
http://git.postgresql.org/pg/commitdiff/be65eddd80093a923b091dc60776aa6f966d1f07

- Remove trailing commas in enums. These aren't valid C89. Found
thanks to gcc's -Wc90-c99-compat. These exist in differing places in
most supported branches.
http://git.postgresql.org/pg/commitdiff/533cd2303aa6558721e76295fd1ffb05211764f9

- Make init_spin_delay() C89 compliant #2. My previous attempt at
doing so, in 80abbeba23, was not sufficient. While that fixed the
problem for bufmgr.c and lwlock.c , s_lock.c still has non-constant
expressions in the struct initializer, because the
file/line/function information comes from the caller of s_lock().
Give up on using a macro, and use a static inline instead.
Discussion: 4369(dot)1460435533(at)sss(dot)pgh(dot)pa(dot)us
http://git.postgresql.org/pg/commitdiff/4b74c6a40e7ac9dad7cdeb4cfd2d51ea60cfdbb5

- Fix trivial typo.
http://git.postgresql.org/pg/commitdiff/7b16781228d6c0a2db66d71e33e64b9606779feb

Magnus Hagander pushed:

- Update helptext for vcregress.pl. This has clearly not been
tracking the code changse for quite some time. Michael Paquier,
problem spotted by Kyotaro HORIGUCHI
http://git.postgresql.org/pg/commitdiff/cf086b1c2fa1e11c14a9fe5fea05553974a480ef

- Fix typo in comment
http://git.postgresql.org/pg/commitdiff/ba8fe38f58e2f3d86c5361373598af80d5ce4443

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Michaël Paquier sent in two more revisions of a patch to add VS 2015
support to MSVC.

Robert Haas sent in a patch to fix some alignment issues in
src/backend/storage/buffer/buf_init.c.

Stas Kelvich and Michaël Paquier traded patches to speed up two-phase
commits.

Etsuro Fujita sent in a patch to improve the way foreign tables get
written to in the PostgreSQL FDW.

Anastasia Lubennikova sent in another revision of a patch to implement
covering unique indexes.

Amit Kapila sent in a patch to pad the PGXACT struct out to 64 bytes.

Teodor Sigaev sent in a patch to fix some GIN index corruption bugs.

David Rowley sent in two revisions of a patch to fix some issues with
EXPLAIN output for parallel aggregates.

Ashutosh Sharma fix an issue with pg_basebackup's handling of
symlinks.

Peter Geoghegan sent in a patch to remove an obsolete comment from
fmgr.c.

Amit Langote sent in another revision of a patch to implement
declarative partitioning.

Michaël Paquier sent in three more revisions of a patch to fix
interrupt handling in the PostgreSQL FDW.

David Rowley sent in three revisions of a patch to disallow creating
unique indexes on system columns where that doesn't make sense.

Etsuro Fujita sent in a patch to fix an issue where a combination of
FULL and INNER joins could produce a wrong result with the PostgreSQL
FDW.

Feike Steenbergen sent in a patch to make pg_get_functiondef actually
add parallel indicators.

Piotr Stefaniak sent in another revision of a patch to avoid passing
null pointers to functions that require the pointers to be non null.

Magnus Hagander sent in a patch to fix some issues with the backup
docs.

Craig Ringer sent in a patch to enable logical timeline following in
the walsender.

Terence Ferraro sent in a patch to make it possible for an environment
variable to be provided to libpq to specify where to find the SSL
certificate/key files used for a secure connection.

Browse pgsql-announce by date

  From Date Subject
Next Message Umair Shahid 2016-04-18 11:57:48 Postgres-XL 9.5 R1 Released
Previous Message David Steele 2016-04-17 13:06:07 pgBackRest 1.0 Released