== PostgreSQL Weekly News - March 15 2015 ==

== PostgreSQL Weekly News - March 15 2015 ==

== PostgreSQL Product News ==

cstore_fdw 1.2, a columnar store extension for PostgreSQL, released
https://www.citusdata.com/blog/14-marco/120-cstore-fdw-1-2-release-notes

PG Partition Manager 1.8.2, an extension to manage time- or
serial-based table partitioning, released.
https://github.com/keithf4/pg_partman

pg_repack 1.3.1, a utility for removing bloat and restoring the
physical ordering of clustered indexes on line, released.
http://reorg.github.com/pg_repack/

pitrery 1.8, a set of bash scripts to manage PITR backups for
PostgreSQL, released.
http://dalibo.github.io/pitrery/

PostgreDAC 3.0.0 a Delphi/C++ builder for PostgreSQL, released.
http://microolap.com/products/connectivity/postgresdac/download/

== PostgreSQL Jobs for March ==

http://archives.postgresql.org/pgsql-jobs/2015-03/threads.php

== PostgreSQL Local ==

PGConf US 2015 takes place March 25-27, 2015 in NYC.
http://nyc.pgconf.us/2015/

The CfP for the second Swiss Postgres Conference, to be held June
25-26, 2015 at HSR Rapperswil, is open until April 1.
http://www.postgres-conference.ch/cfp/

The constituent assembly of the Swiss PostgreSQL
Users Group (SwissPUG) will be Friday, April 10, 2015
http://www.swisspug.org

India PostgreSQL UserGroup will hold a PGday in Bengaluru, Karnataka,
India on April 11, 2015. RSVP at
http://www.meetup.com/India-PUG/events/220553997/

There is a Postgres track in a database technology conference(DTCC) in
April 18, 2015 in Beijing, China.
http://dtcc.it168.com/list_jiabin.html

pgDay Paris will be held in Paris France on April 21, 2015.
http://pgday.paris/

PGCon 2015 is June 16-20 in Ottawa, Canada.
http://www.pgcon.org/2015/

== 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:

- Add missing "goto err" statements in xlogreader.c. Spotted by
Andres Freund.
http://git.postgresql.org/pg/commitdiff/c74c04b8aa03f05983f940ee94c86a5cc1945393

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

- Suppress maybe-uninitialized compiler warnings. Previously some
compilers were thinking that the variables that 57aa5b2 added
maybe-uninitialized. Spotted by Andres Freund
http://git.postgresql.org/pg/commitdiff/cd6c45cbeec5e21b470e9a8d19e02f60f1a52807

- Add GUC to enable compression of full page images stored in WAL.
When newly-added GUC parameter, wal_compression, is on, the
PostgreSQL server compresses a full page image written to WAL when
full_page_writes is on or during a base backup. A compressed page
image will be decompressed during WAL replay. Turning this parameter
on can reduce the WAL volume without increasing the risk of
unrecoverable data corruption, but at the cost of some extra CPU
spent on the compression during WAL logging and on the decompression
during WAL replay. This commit changes the WAL format (so bumping
WAL version number) so that the one-byte flag indicating whether a
full page image is compressed or not is included in its header
information. This means that the commit increases the WAL volume
one-byte per a full page image even if WAL compression is not used
at all. We can save that one-byte by borrowing one-bit from the
existing field like hole_offset in the header and using it as the
flag, for example. But which would reduce the code readability and
the extensibility of the feature. Per discussion, it's not worth
paying those prices to save only one-byte, so we decided to add the
one-byte flag to the header. This commit doesn't introduce any new
compression algorithm like lz4. Currently a full page image is
compressed using the existing PGLZ algorithm. Per discussion, we
decided to use it at least in the first version of the feature
because there were no performance reports showing that its
compression ratio is unacceptably lower than that of other
algorithm. Of course, in the future, it's worth considering the
support of other compression algorithm for the better compression.
Rahila Syed and Michael Paquier, reviewed in various versions by
myself, Andres Freund, Robert Haas, Abhijit Menon-Sen and many
others.
http://git.postgresql.org/pg/commitdiff/57aa5b2bb11a4dbfdfc0f92370e0742ae5aa367b

Michael Meskes pushed:

- Ignore object files generated by ecpg test suite on Windows. Patch
by Michael Paquier
http://git.postgresql.org/pg/commitdiff/b9e538b190d9cf4387361214eadc430393ebf852

- Ignore leftover artifacts from ecpg testsuite runs on Windows.
http://git.postgresql.org/pg/commitdiff/fa83f809458a966dff225d3d266399d48e7b5e6e

- Revert "Ignore object files generated by ecpg test suite on Windows"
This reverts commit b9e538b190d9cf4387361214eadc430393ebf852.
http://git.postgresql.org/pg/commitdiff/2093eb4d4c2b55962df613fdd6f605ce4dc67217

Heikki Linnakangas pushed:

- Move WAL-related definitions from dbcommands.h to separate header
file. This makes it easier to write frontend programs that needs to
understand the WAL record format of CREATE/DROP DATABASE.
dbcommands.h cannot easily be #included in a frontend program,
because it pulls in other header files that need backend stuff, but
the new dbcommands_xlog.h header file has fewer dependencies.
http://git.postgresql.org/pg/commitdiff/f1fd515b393a283d7368ce45a92709d2c7f9a991

- Fix memory leaks in GIN index vacuum. Per bug #12850 by Walter
Nordmann. Backpatch to 9.4 where the leak was introduced.
http://git.postgresql.org/pg/commitdiff/26d2c5dc8dc24febee8c3dd472407d7bbdcc245d

Robert Haas pushed:

- Fix handling of sortKeys field in Tuplesortstate. Commit
5cefbf5a6c4466ac6b1cc2a4316b4eba9108c802 introduced an assumption
that this field would always be non-NULL when doing a merge pass,
but that's not true. Without this fix, you can crash the server by
building a hash index that is sufficiently large relative to
maintenance_work_mem, or by triggering a large datum sort. Commit
5ea86e6e65dd2da3e9a3464484985d48328e7fe3 changed the comments for
that field to say that it would be set in all cases except for the
hash index case, but that wasn't (and still isn't) true. The
datum-sort failure was spotted by Tomas Vondra; initial analysis of
that failure was by Peter Geoghegan. The remaining issues were
spotted by me during review of the surrounding code, and the patch
is all my fault.
http://git.postgresql.org/pg/commitdiff/2720e96a9bd58b2af177c714c0c5402773e1cf30

- Allow named parameters to be specified using => in addition to :=
SQL has standardized on => as the use of to specify named
parameters, and we've wanted for many years to support the same
syntax ourselves, but this has been complicated by the possible use
of => as an operator name. In PostgreSQL 9.0, we began emitting a
warning when an operator named => was defined, and in PostgreSQL
9.2, we stopped shipping a =>(text, text) operator as part of
hstore. By the time the next major version of PostgreSQL is
released, => will have been deprecated for a full five years, so
hopefully there won't be too many people still relying on it. We
continue to support := for compatibility with previous PostgreSQL
releases. Pavel Stehule, reviewed by Petr Jelinek, with a few
documentation tweaks by me.
http://git.postgresql.org/pg/commitdiff/865f14a2d31af23a05bbf2df04c274629c5d5c4d

- Suggest to the user the column they may have meant to reference.
Error messages informing the user that no such column exists can
sometimes provoke a perplexed response. This often happens due to a
subtle typo in the column name or, perhaps less likely, in the alias
name. To speed discovery of what the real issue is in such cases,
we'll now search the range table for approximate matches. If there
are one or two such matches that are good enough to think that they
might be what the user intended to type, and better than all other
approximate matches, we'll issue a hint suggesting that the user
might have intended to reference those columns. Peter Geoghegan and
Robert Haas
http://git.postgresql.org/pg/commitdiff/e529cd4ffa605c6f14f1391af5559b3a44da0336

- sepgsql: Improve error message when unsupported object type is
labeled. KaiGai Kohei, reviewed by Álvaro Herrera and myself
http://git.postgresql.org/pg/commitdiff/e96b7c6b9fc4d148a22588894245416b63743368

- Require non-NULL pstate for all addRangeTableEntryFor* functions.
Per discussion, it's better to have a consistent coding rule here.
Michael Paquier, per a node from Greg Stark referencing an old post
from Tom Lane.
http://git.postgresql.org/pg/commitdiff/bc93ac12c2544b6b3a68b6cb0282e0828fa14a34

- Document the new custom scan APIs. These APIs changed somewhat
subsequent to the initial commit, and may change further in the
future, but let's document what we have today. KaiGai Kohei and
Robert Haas, reviewed by Tom Lane and Thom Brown
http://git.postgresql.org/pg/commitdiff/82fe8b1119e4187f3d991564274607b0b4089aca

Álvaro Herrera pushed:

- Allow CURRENT/SESSION_USER to be used in certain commands. Commands
such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the various
ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to roles
such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause of
CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER
as user specifiers in place of an explicit user name. This commit
also fixes some quite ugly handling of special standards- mandated
syntax in CREATE USER MAPPING, which in particular would fail to
work in presence of a role named "current_user". The special role
specifiers PUBLIC and NONE also have more consistent handling now.
Also take the opportunity to add location tracking to user
specifiers. Authors: Kyotaro Horiguchi. Heavily reworked by Álvaro
Herrera. Reviewed by: Rushabh Lathia, Adam Brightwell, Marti
Raudsepp.
http://git.postgresql.org/pg/commitdiff/31eae6028eca4365e7165f5f33fee1ed0486aee0

- Fix crasher bugs in previous commit. ALTER DEFAULT PRIVILEGES was
trying to decode the list of roles in the FOR clause as a list of
names rather than of RoleSpecs; and the IN clause in CREATE ROLE was
doing the same thing. This was evidenced by crashes on some
buildfarm machines, though on my platform this doesn't cause a
failure by mere chance; I can reproduce the failures only by adding
some padding in struct RoleSpecs. Fix by dereferencing those lists
as being of RoleSpecs, not string Values.
http://git.postgresql.org/pg/commitdiff/e3f1c24b992acb88e4ccf33118640aee4b11dd47

- Keep CommitTs module in sync in standby and master. We allow this
module to be turned off on restarts, so a restart time check is
enough to activate or deactivate the module; however, if there is a
standby replaying WAL emitted from a master which is restarted, but
the standby isn't, the state in the standby becomes inconsistent and
can easily be crashed. Fix by activating and deactivating the
module during WAL replay on parameter change as well as on system
start. Problem reported by Fujii Masao in
http://www.postgresql.org/message-id/CAHGQGwFhJ3CnHo1CELEfay18yg_RA-XZT-7D8NuWUoYSZ90r4Q@mail.gmail.com
Author: Petr Jelínek
http://git.postgresql.org/pg/commitdiff/4f3924d9cd438ba4e6fd639460f8c859c65d45a3

- Fix stray sentence fragment in shared_preload_libraries
documentation. The introduction in the Shared Library Preloading
section already instructs the user to separate multiple library
names with commas, so just remove the fragment from here. Author:
Dagfinn Ilmari Mannsåker
http://git.postgresql.org/pg/commitdiff/bb7b35caf78de80d2ff1643d042e62a71f83abbb

- Move BRIN page type to page's last two bytes. ... which is the
usual convention among AMs, so that pg_filedump and similar
utilities can tell apart pages of different AMs. It was also the
intent of the original code, but I failed to realize that alignment
considerations would move the whole thing to the previous-to-last
word in the page. The new definition of the associated macro makes
surrounding code a bit leaner, too. Per note from Heikki at
http://www.postgresql.org/message-id/546A16EF.9070005@vmware.com
http://git.postgresql.org/pg/commitdiff/e491bd2ee34860b14ff18abc5602f9aa5b197a2d

- Refactor Mkvcbuild.pm to facilitate modules migrations. This is in
preparation to "upgrade" some modules from contrib/ to src/bin/, per
discussion. Author: Michael Paquier
http://git.postgresql.org/pg/commitdiff/66ece312f99f384bd33e4342580e78b0eebf0e74

- Support user mappings in get_object_address. Since commit
72dd233d3ef we were trying to obtain object addressing information
in sql_drop event triggers, but that caused failures when the drops
involved user mappings. This addition enables that to work again.
Naturally, pg_get_object_address can work with these objects now,
too. I toyed with the idea of removing DropUserMappingStmt as a
node and using DropStmt instead in the DropUserMappingStmt grammar
production, but that didn't go very well: for one thing the messages
thrown by the specific code are specialized (you get "server not
found" if you specify the wrong server, instead of a generic "user
mapping for ... not found" which you'd get it we were to merge this
with RemoveObjects --- unless we added even more special cases).
For another thing, it would require to pass RoleSpec nodes through
the objname/objargs representation used by RemoveObjects, which
works in isolation, but gets messy when pg_get_object_address is
involved. So I dropped this part for now. Reviewed by Stephen
Frost.
http://git.postgresql.org/pg/commitdiff/890192e99af5db1d15d5bb73f3f1044faa1d2758

- Fix libpq test expected output file. Evidently, this test is not
run very frequently ...
http://git.postgresql.org/pg/commitdiff/d4d7777548ed3ea2ca579003e37f9df4d0e0ab9e

- Support default ACLs in get_object_address. In the spirit of
890192e99af, this time add support for the things living in the
pg_default_acl catalog. These are not really "objects", but they
show up as such in event triggers. There is no "DROP DEFAULT
PRIVILEGES" or similar command, so it doesn't look like the new
representation given would be useful anywhere else, so I didn't try
to use it outside objectaddress.c. (That might be a bug in itself,
but that would be material for another commit.) Reviewed by Stephen
Frost.
http://git.postgresql.org/pg/commitdiff/4464303405f1f886d63f8316386621cd7436c5d6

Tom Lane pushed:

- Clean up the mess from => patch. Commit
865f14a2d31af23a05bbf2df04c274629c5d5c4d was quite a few bricks shy
of a load: psql, ecpg, and plpgsql were all left out-of-step with
the core lexer. Of these only the last was likely to be a fatal
problem; but still, a minimal amount of grepping, or even just
reading the comments adjacent to the places that were changed, would
have found the other places that needed to be changed.
http://git.postgresql.org/pg/commitdiff/2fbb286647fac2014abdf2fbf6c7b4134be91602

- Allocate ParamListInfo once per plpgsql function, not once per
expression. setup_param_list() was allocating a fresh ParamListInfo
for each query or expression evaluation requested by a plpgsql
function. There was probably once good reason to do it like that,
but for a long time we've had a convention that there's a one-to-one
mapping between the function's PLpgSQL_datum array and the
ParamListInfo slots, which means that a single ParamListInfo can
serve all the function's evaluation requests: the data that would
need to be passed is the same anyway. In this patch, we retain the
pattern of zeroing out the ParamListInfo contents during each
setup_param_list() call, because some of the slots may be stale and
we don't know exactly which ones. So this patch only saves a
palloc/pfree per evaluation cycle and nothing more; still, that
seems to be good for a couple percent overall speedup on
simple-arithmetic type statements. In future, though, we might be
able to improve matters still more by managing the param array
contents more carefully. Also, unify the former use of
estate->cur_expr with that of paramLI->parserSetupArg; they both
were used to point to the active expression, so we can combine the
variables into just one.
http://git.postgresql.org/pg/commitdiff/21dcda2713656a7483e3280ac9d2ada20a87a9a9

- Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of
operator precedence (because it never presents a unified BNF for all
expressions), it does seem reasonable to conclude from the spec for
<boolean value expression> that OR has the lowest precedence, then
AND, then NOT, then IS tests, then the six standard comparison
operators, then everything else (since any non-boolean operator in a
WHERE clause would need to be an argument of one of these). We were
only sort of on board with that: most notably, while "<" ">" and "="
had properly low precedence, "<=" ">=" and "<>" were treated as
generic operators and so had significantly higher precedence. And
"IS" tests were even higher precedence than those, which is very
clearly wrong per spec. Another problem was that "foo NOT SOMETHING
bar" constructs, such as "x NOT LIKE y", were treated inconsistently
because of a bison implementation artifact: they had the documented
precedence with respect to operators to their right, but behaved
like NOT (i.e., very low priority) with respect to operators to
their left. Fixing the precedence issues is just a small matter of
rearranging the precedence declarations in gram.y, except for the
NOT problem, which requires adding an additional lookahead case in
base_yylex() so that we can attach a different token precedence to
NOT LIKE and allied two-word operators. The bulk of this patch is
not the bug fix per se, but adding logic to parse_expr.c to allow
giving warnings if an expression has changed meaning because of
these precedence changes. These warnings are off by default and are
enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it
was agreed that a warning mechanism is essential to help debug any
that are.
http://git.postgresql.org/pg/commitdiff/c6b3c939b7e0f1d35f4ed4996e71420a993810d2

- Improve planner's cost estimation in the presence of semijoins. If
we have a semijoin, say SELECT * FROM x WHERE x1 IN (SELECT y1 FROM
y) and we're estimating the cost of a parameterized indexscan on x,
the number of repetitions of the indexscan should not be taken as
the size of y; it'll really only be the number of distinct values of
y1, because the only valid plan with y on the outside of a nestloop
would require y to be unique-ified before joining it to x. Most of
the time this doesn't make that much difference, but sometimes it
can lead to drastically underestimating the cost of the indexscan
and hence choosing a bad plan, as pointed out by David Kubečka.
Fixing this is a bit difficult because parameterized indexscans are
costed out quite early in the planning process, before we have the
information that would be needed to call estimate_num_groups() and
thereby estimate the number of distinct values of the join
column(s). However we can move the code that extracts a semijoin
RHS's unique-ification columns, so that it's done in initsplan.c
rather than on-the-fly in create_unique_path(). That shouldn't make
any difference speed-wise and it's really a bit cleaner too. The
other bit of information we need is the size of the semijoin RHS,
which is easy if it's a single relation (we make those estimates
before considering indexscan costs) but problematic if it's a join
relation. The solution adopted here is just to use the product of
the sizes of the join component rels. That will generally be an
overestimate, but since estimate_num_groups() only uses this input
as a clamp, an overestimate shouldn't hurt us too badly. In any
case we don't allow this new logic to produce a value larger than we
would have chosen before, so that at worst an overestimate leaves us
no wiser than we were before.
http://git.postgresql.org/pg/commitdiff/b55722692ba0ceb934bb32bcddb562e2120f43dd

- Fix old bug in get_loop_count(). While poking at David Kubečka's
issue I noticed an ancient logic error in get_loop_count(): it used
1.0 as a "no data yet" indicator, but since that is actually a valid
rowcount estimate, this doesn't work. If we have one input relation
with 1.0 as rowcount and then another one with a larger rowcount, we
should use 1.0 as the result, but we picked the larger rowcount
instead. (I think when I coded this, I recognized the conflict, but
mistakenly thought that the logic would pick the desired count
anyway.) Fixing this changed the plan for one existing regression
test case. Since the point of that test is to exercise creation of
a particular shape of nestloop plan, I tweaked the query a little
bit so it still results in the same plan choice. This is definitely
a bug, but I'm hesitant to back-patch since it might change plan
choices unexpectedly, and anyway failure to implement a heuristic
precisely as intended is a pretty low-grade bug.
http://git.postgresql.org/pg/commitdiff/b746d0c32d4fe749c8d39ccb09d8f0fb38bcc197

- Support flattening of empty-FROM subqueries and one-row VALUES
tables. We can't handle this in the general case due to limitations
of the planner's data representations; but we can allow it in many
useful cases, by being careful to flatten only when we are pulling a
single-row subquery up into a FROM (or, equivalently, inner JOIN)
node that will still have at least one remaining relation child.
Per discussion of an example from Kyotaro Horiguchi.
http://git.postgresql.org/pg/commitdiff/f4abd0241de20d5d6a79b84992b9e88603d44134

- Ensure tableoid reads correctly in EvalPlanQual-manufactured tuples.
The ROW_MARK_COPY path in EvalPlanQualFetchRowMarks() was just
setting tableoid to InvalidOid, I think on the assumption that the
referenced RTE must be a subquery or other case without a meaningful
OID. However, foreign tables also use this code path, and they do
have meaningful table OIDs; so failure to set the tuple field can
lead to user-visible misbehavior. Fix that by fetching the
appropriate OID from the range table. There's still an issue about
whether CTID can ever have a meaningful value in this case; at least
with postgres_fdw foreign tables, it does. But that is a different
problem that seems to require a significantly different patch ---
it's debatable whether postgres_fdw really wants to use this code
path at all. Simplified version of a patch by Etsuro Fujita, who
also noted the problem to begin with. The issue can be demonstrated
in all versions having FDWs, so back-patch to 9.1.
http://git.postgresql.org/pg/commitdiff/443fd0540e298b621be6748dead1fb444556e0d0

- Improve documentation of bt_page_items(). Explain some of the funny
conventions used in btree page items. Peter Geoghegan and Jeff
Janes
http://git.postgresql.org/pg/commitdiff/ebc0f5e01d2f4b7d7c3307fd4d40498f6b120898

- Remove workaround for ancient incompatibility between readline and
libedit. GNU readline defines the return value of write_history()
as "zero if OK, else an errno code". libedit's version of that
function used to have a different definition (to wit, "-1 if error,
else the number of lines written to the file"). We tried to work
around that by checking whether errno had become nonzero, but this
method has never been kosher according to the published API of
either library. It's reportedly completely broken in recent Ubuntu
releases: psql bleats about "No such file or directory" when saving
~/.psql_history, even though the write worked fine. However,
libedit has been following the readline definition since somewhere
around 2006, so it seems all right to finally break compatibility
with ancient libedit releases and trust that the return value is
what readline specifies. (I'm not sure when the various Linux
distributions incorporated this fix, but I did find that OS X has
been shipping fixed versions since 10.5/Leopard.) If anyone is still
using such an ancient libedit, they will find that psql complains it
can't write ~/.psql_history at exit, even when the file was written
correctly. This is no worse than the behavior we're fixing for
current releases. Back-patch to all supported branches.
http://git.postgresql.org/pg/commitdiff/df9ebf1eeaf98481e00cd77bf6056d42310731b7

- Build src/port/dirmod.c only on Windows. Since commit
ba7c5975adea74c6f17bdb0e0427ad85962092a2, port/dirmod.c has
contained only Windows-specific functions. Most platforms don't
seem to mind uselessly building an empty file, but OS X for one
issues warnings. Hence, treat dirmod.c as a Windows-specific file
selected by configure rather than one that's always built. We can
revert this change if dirmod.c ever gains any non-Windows
functionality again. Back-patch to 9.4 where the mentioned commit
appeared.
http://git.postgresql.org/pg/commitdiff/91f4a5a976500517e492320e389342d7436cf9d4

- Remove obsolete comment. Obsoleted by commit
21dcda2713656a7483e3280ac9d2ada20a87a9a9, but I missed seeing the
cross-reference in the comments for exec_eval_integer(). Also
improve the cross-reference in the comments for exec_eval_cleanup().
http://git.postgresql.org/pg/commitdiff/5ff683962ef9a953eeb17ea58d678f0c4ca189ae

- Add missing documentation for PGC_SU_BACKEND in description of
pg_settings. Commit fe550b2ac249af5fbd8e9e19290a4ba43c882f2d missed
updating this list of the PGC_XXX values, which in hindsight is not
so surprising because catalogs.sgml is not a place you'd think to
look for them. In addition to adding the missing doco, insert the
PGC_XXX C enum names in SGML comments, so that grepping for the enum
names will find this file. That might spare the next person similar
embarrassment. Spotted by Magnus Hagander.
http://git.postgresql.org/pg/commitdiff/d1e9214e4ff5604357d0155467f105825a9e102c

- src/port/dirmod.c needs to be built on Cygwin too. Oversight in my
commit 91f4a5a976500517e492320e389342d7436cf9d4. Per buildfarm
member brolga.
http://git.postgresql.org/pg/commitdiff/80089597730f67927293c410914f3e6bf11ca447

- Move LockClauseStrength, LockWaitPolicy into new file
nodes/lockoptions.h. Commit
df630b0dd5ea2de52972d456f5978a012436115e moved enum LockWaitPolicy
into its very own header file utils/lockwaitpolicy.h, which does not
seem like a great idea from here. First, it's still a node-related
declaration, and second, a file named like that can never sensibly
be used for anything else. I do not think we want to encourage a
one-typedef-per-header-file approach. The upcoming foreign table
inheritance patch was doubling down on this bad idea by moving enum
LockClauseStrength into its *own*
can-never-be-used-for-anything-else file. Instead, let's put them
both in a file named nodes/lockoptions.h. (They do seem to need a
separate header file because we need them in both parsenodes.h and
plannodes.h, and we don't want either of those including the other.
Past practice might suggest adding them to nodes/nodes.h, but they
don't seem sufficiently globally useful to justify that.) Committed
separately since there's no functional change here, just some
header-file refactoring.
http://git.postgresql.org/pg/commitdiff/9fac5fd741ec17ae24dde6b8e82064f13c148ddf

- Improve representation of PlanRowMark. This patch fixes two
inadequacies of the PlanRowMark representation. First, that the
original LockingClauseStrength isn't stored (and cannot be inferred
for foreign tables, which always get ROW_MARK_COPY). Since some
PlanRowMarks are created out of whole cloth and don't actually have
an ancestral RowMarkClause, this requires adding a dummy LCS_NONE
value to enum LockingClauseStrength, which is fairly annoying but
the alternatives seem worse. This fix allows getting rid of the use
of get_parse_rowmark() in FDWs (as per the discussion around commits
462bd95705a0c23b and 8ec8760fc87ecde0), and it simplifies some
things elsewhere. Second, that the representation assumed that all
child tables in an inheritance hierarchy would use the same
RowMarkType. That's true today but will soon not be true. We add
an "allMarkTypes" field that identifies the union of mark types used
in all a parent table's children, and use that where appropriate
(currently, only in preprocess_targetlist()). In passing fix a
couple of minor infelicities left over from the SKIP LOCKED patch,
notably that _outPlanRowMark still thought waitPolicy is a bool.
Catversion bump is required because the numeric values of enum
LockingClauseStrength can appear in on-disk rules. Extracted from a
much larger patch to support foreign table inheritance; it seemed
worth breaking this out, since it's a separable concern. Shigeru
Hanada and Etsuro Fujita, somewhat modified by me
http://git.postgresql.org/pg/commitdiff/7b8b8a43317e9e59eca8b511b714a0ab7da5f1cb

Andres Freund pushed:

- Add macros wrapping all usage of gcc's __attribute__. Until now
__attribute__() was defined to be empty for all compilers but gcc.
That's problematic because it prevents using it in other compilers;
which is necessary e.g. for atomics portability. It's also just
generally dubious to do so in a header as widely included as c.h.
Instead add pg_attribute_format_arg, pg_attribute_printf,
pg_attribute_noreturn macros which are implemented in the compilers
that understand them. Also add pg_attribute_noreturn and
pg_attribute_packed, but don't provide fallbacks, since they can
affect functionality. This means that external code that, possibly
unwittingly, relied on __attribute__ defined to be empty on !gcc
compilers may now run into warnings or errors on those compilers.
But there shouldn't be many occurances of that and it's hard to work
around... Discussion: 54B58BA3(dot)8040302(at)ohmu(dot)fi Author: Oskari
Saarenmaa, with some minor changes by me.
http://git.postgresql.org/pg/commitdiff/bbfd7edae5aa5ad5553d3c7e102f2e450d4380d4

- Adjust valgrind suppressions wrt 025c02420.
http://git.postgresql.org/pg/commitdiff/241f088f3632814fe9dbd5bcbc509ec42a268d01

- Increase max_wal_size's default from 128MB to 1GB. The introduction
of min_wal_size & max_wal_size in 88e982302684 makes it feasible to
increase the default upper bound in checkpoint size. Previously
raising the default would lead to a increased disk footprint, even
if more segments weren't beneficial. The low default of checkpoint
size is one of common performance problem users have thus increasing
the default makes sense. Setups where the increase in maximum disk
usage is a problem will very likely have to run with a modified
configuration anyway. Discussion: 54F4EFB8(dot)40202(at)agliodbs(dot)com,
CA+TgmoZEAgX5oMGJOHVj8L7XOkAe05Gnf45rP40m-K3FhZRVKg(at)mail(dot)gmail(dot)com
Author: Josh Berkus, after a discussion involving lots of people.
http://git.postgresql.org/pg/commitdiff/a0f5954af19ddcfea946b15744f2006a789dc4bd

- Remove pause_at_recovery_target recovery.conf setting. The new
recovery_target_action (introduced in aedccb1f6/b8e33a85d4) replaces
it's functionality. Having both seems likely to cause more confusion
than it saves worry due to the incompatibility. Discussion:
5484FC53(dot)2060903(at)2ndquadrant(dot)com Author: Petr Jelinek
http://git.postgresql.org/pg/commitdiff/51c11a7025ecc10c2b922d60a056ad7c6cf147a5

- Merge the various forms of transaction commit & abort records.
Since 465883b0a two versions of commit records have existed. A
compact version that was used when no cache invalidations, smgr
unlinks and similar were needed, and a full version that could deal
with all that. Additionally the full version was embedded into
twophase commit records. That resulted in a measurable reduction in
the size of the logged WAL in some workloads. But more recently
additions like logical decoding, which e.g. needs information about
the database something was executed on, made it applicable in fewer
situations. The static split generally made it hard to expand the
commit record, because concerns over the size made it hard to add
anything to the compact version. Additionally it's not particularly
pretty to have twophase.c insert RM_XACT records. Rejigger things
so that the commit and abort records only have one form each,
including the twophase equivalents. The presence of the various
optional (in the sense of not being in every record) pieces is
indicated by a bits in the 'xinfo' flag. That flag previously was
not included in compact commit records. To prevent an increase in
size due to its presence, it's only included if necessary; signalled
by a bit in the xl_info bits available for xact.c, similar to
heapam.c's XLOG_HEAP_OPMASK/XLOG_HEAP_INIT_PAGE. Twophase
commit/aborts are now the same as their normal counterparts. The
original transaction's xid is included in an optional data field.
This means that commit records generally are smaller, except in the
case of a transaction with subtransactions, but no other special
cases; the increase there is four bytes, which seems acceptable
given that the more common case of not having subtransactions
shrank. The savings are especially measurable for twophase commits,
which previously always used the full version; but will in practice
only infrequently have required that. The motivation for this work
are not the space savings and and deduplication though; it's that it
makes it easier to extend commit records with additional
information. That's just a few lines of code now; without impacting
the common case where that information is not needed. Discussion:
20150220152150(dot)GD4149(at)awork2(dot)anarazel(dot)de,
235610.92468.qm%40web29004.mail.ird.yahoo.com Reviewed-By: Heikki
Linnakangas, Simon Riggs
http://git.postgresql.org/pg/commitdiff/4f1b890b1377744688e43218f975d3c8b2ae39f8

Peter Eisentraut pushed:

- PL/Python: Avoid lossiness in float conversion. PL/Python uses
str() to convert Python values back to PostgreSQL, but str() is
lossy for float values, so use repr() instead in that case. Author:
Marko Kreen <markokr(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/1ce7a57ca6e8c5212fa2ab3bf31d56c74d5b5b8f

- PL/Python: Fix regression tests for Python 3
http://git.postgresql.org/pg/commitdiff/ff2faeec5c77539f3c64e6e7d94af1b00a168d10

- doc: Remove link to outdated dtrace project on pgfoundry
http://git.postgresql.org/pg/commitdiff/959df4b5fc81397ddc8926d6b756dc044310fa34

Tatsuo Ishii pushed:

- Fix integer overflow in debug message of walreceiver. The message
tries to tell the replication apply delay which fails if the first
WAL record is not applied yet. Fix is, instead of telling overflowed
minus numeric, showing "N/A" which indicates that the delay data is
not yet available. Problem reported by me and patch by Fabrízio de
Royes Mello. Back patched to 9.4, 9.3 and 9.2 stable branches (9.1
and 9.0 do not have the debug message).
http://git.postgresql.org/pg/commitdiff/364c006c1fba7ba7825fb06ef0166e752546f357

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Michael Paquier sent in two more revisions of a patch to speed up make
check-world.

Dmitry Voronin sent in another revision of a patch to add some new
functions to contrib/sslinfo.

Michael Paquier sent in two more revisions of a patch to install
shared libs in lib/ and bin/ with MSVC (Was: install libpq.dll in bin
directory on Windows / Cygwin.

Kaigai Kouhei sent in another revision of a patch to add join
push-down support for foreign tables.

SAWADA Masahiko sent in three more revisions of a patch to add REINDEX
xxx VERBOSE.

Andrew (RhodiumToad) Gierth sent in two more revisions of a patch to
add GROUPING SETS.

Amit Kapila and Amit Langote traded patches to add parallel sequential
scan.

Kevin Grittner sent in three more revisions of a patch to reduce
pinning in btree indexes.

Kaigai Kouhei sent in another revision of a patch to add a custom plan
API.

Kaigai Kouhei and Robert Haas traded patches for the custom join API.

Heikki Linnakangas sent in three more revisions of a patch to add
pg_rewind.

Andreas Karlsson sent in three more revisions of a patch to use
128-bit integers for sum, avg and statistics aggregates.

Abhijit Menon-Sen sent in another revision of a patch to recursively
fsync PGDATA at startup if needed.

Kyotaro HORIGUCHI sent in another revision of a patch to make an
effort to send feedback regulary on heavy load.

Tom Lane sent in a patch to fix some inefficiencies in PL/pgsql.

Robert Haas sent in another revision of a patch to do better at
HINTing at a missing column.

Michael Paquier and Peter Eisentraut traded flocks of patches intended
to move binaries from contrib/ to bin/.

Jim Nasby and Pavel Stehule traded patches to add an array_offset
function.

Kyotaro HORIGUCHI sent in another revision of a patch to add regrole.

SAWADA Masahiko sent in another revision of a patch to add a
pg_file_settings view.

Fabien COELHO sent in another revision of a patch to improve pgbench
syntax error messages.

Gregory Stark sent in another revision of a patch to provide a catalog
view to pg_hba.conf file.

Kyotaro HORIGUCHI sent in another revision of a patch to add alter
user/role CURRENT_USER.

Jozef Mlich sent in a patch to use the tcl binary in the PL/tcl
scripts rather than invoking them as shell programs.

Marko (johto) Tiikkaja sent in a patch to fix a bug in dumping views
with circular dependencies.

Stas Kelvich sent in another revision of a patch to add cube extension
KNN support.

Álvaro Herrera sent in a patch to support opfamily members in
get_object_address.

Robert Haas sent in another revision of a patch to help assessing
parallel-safety.

Michael Paquier sent in another revision of a patch to fix the slash
leanings in the MSVC build code.

Michael Paquier sent in a patch to move freeze parameters of
VacuumStmt into a separate structure.

Tomas Vondra sent in a patch to fix an xloginsert.c hole_length
warning on gcc 4.8.3.

Peter Geoghegan sent in another revision of a patch to do datumsort
revisions for abbreviated keys.

Julien Tachoires sent in two more revisions of a patch to allow toast
tables to be moved to a different tablespace.

David Rowley sent in another revision of a patch to improve
performance for for joins where outer side is unique.

Pavel Stehule sent in a patch to add a --strict tablename parameter to
pg_dump.

Andreas Karlsson sent in a patch to fix support for the
--no-tablespaces flag for pg_dump.

Tom Lane sent in a patch to remove setup_param_list() overhead for the
common case of PLPGSQL_DTYPE_VAR variables (ie, any non-composite
type).

Petr (PJMODOS) Jelinek sent in another revision of a patch to
implement TABLESAMPLE.

Andres Freund sent in another revision of a patch to merge compact/non
compact commits, and make aborts dynamically sized.

Petr (PJMODOS) Jelinek sent in another revision of a patch to create a
sequence access method.