== PostgreSQL Weekly News - March 01 2015 ==

== PostgreSQL Weekly News - March 01 2015 ==

The Manchester England PostgreSQL Users' Group is rebooting March 4th.
Details and R, SVP, below.
http://www.meetup.com/The-Manchester-PostgreSQL-Meetup/

== PostgreSQL Local ==

pgDaySF 2015 will be held March 10, 2015 in Burlingame, California.
http://sfpostgres.org/pgday-sf-2015-call-for-speakers-and-sponsors/

Registration for Nordic PostgreSQL Day, March 11, 2015 in Copenhagen,
Denmark, is open.
http://2015.nordicpgday.org/registration/

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/

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/

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

Heikki Linnakangas pushed:

- Fix potential deadlock with libpq non-blocking mode. If libpq
output buffer is full, pqSendSome() function tries to drain any
incoming data. This avoids deadlock, if the server e.g. sends a lot
of NOTICE messages, and blocks until we read them. However,
pqSendSome() only did that in blocking mode. In non-blocking mode,
the deadlock could still happen. To fix, take a two-pronged
approach: 1. Change the documentation to instruct that when
PQflush() returns 1, you should wait for both read- and write-ready,
and call PQconsumeInput() if it becomes read-ready. That fixes the
deadlock, but applications are not going to change overnight. 2. In
pqSendSome(), drain the input buffer before returning 1. This
alleviates the problem for applications that only wait for
write-ready. In particular, a slow but steady stream of NOTICE
messages during COPY FROM STDIN will no longer cause a deadlock. The
risk remains that the server attempts to send a large burst of data
and fills its output buffer, and at the same time the client also
sends enough data to fill its output buffer. The application will
deadlock if it goes to sleep, waiting for the socket to become
write-ready, before the server's data arrives. In practice, NOTICE
messages and such that the server might be sending are usually
short, so it's highly unlikely that the server would fill its output
buffer so quickly. Backpatch to all supported versions.
http://git.postgresql.org/pg/commitdiff/2a3f6e368babdac7b586a7d43105af60fc08b1a3

- Refactor unit conversions code in guc.c. Replace the if-switch-case
constructs with two conversion tables, containing all the supported
conversions between human-readable unit strings and the base units
used in GUC variables. This makes the code easier to read, and makes
adding new units simpler.
http://git.postgresql.org/pg/commitdiff/1b6302647302f459fdb63008c3842a1b0d43d1b7

- Renumber GUC_* constants. This moves all the regular flags back
together (for aesthetic reasons), and makes room for more GUC_UNIT_*
types.
http://git.postgresql.org/pg/commitdiff/0fec000365c25fd89ea583673de226e816dba60f

- Replace checkpoint_segments with min_wal_size and max_wal_size.
Instead of having a single knob (checkpoint_segments) that both
triggers checkpoints, and determines how many checkpoints to
recycle, they are now separate concerns. There is still an internal
variable called CheckpointSegments, which triggers checkpoints. But
it no longer determines how many segments to recycle at a
checkpoint. That is now auto-tuned by keeping a moving average of
the distance between checkpoints (in bytes), and trying to keep that
many segments in reserve. The advantage of this is that you can set
max_wal_size very high, but the system won't actually consume that
much space if there isn't any need for it. The min_wal_size sets a
floor for that; you can effectively disable the auto-tuning behavior
by setting min_wal_size equal to max_wal_size. The max_wal_size
setting is now the actual target size of WAL at which a new
checkpoint is triggered, instead of the distance between
checkpoints. Previously, you could calculate the actual WAL usage
with the formula "(2 + checkpoint_completion_target) *
checkpoint_segments + 1". With this patch, you set the desired WAL
usage with max_wal_size, and the system calculates the appropriate
CheckpointSegments with the reverse of that formula. That's a lot
more intuitive for administrators to set. Reviewed by Amit Kapila
and Venkata Balaji N.
http://git.postgresql.org/pg/commitdiff/88e982302684246e8af785e78a467ac37c76dee9

- Fix typo in README. Kyotaro Horiguchi
http://git.postgresql.org/pg/commitdiff/dd58c6098f2f2fcea71c7125f9594268a24a38ad

- Fix recovery_command -> restore_command typo in 8.3 release notes.
Kyotaro Horiguchi
http://git.postgresql.org/pg/commitdiff/347c74320d10bee458d1fec159aeda7143d31bfb

Fujii Masao pushed:

- Add GUC to control the time to wait before retrieving WAL after
failed attempt. Previously when the standby server failed to
retrieve WAL files from any sources (i.e., streaming replication,
local pg_xlog directory or WAL archive), it always waited for five
seconds (hard-coded) before the next attempt. For example, this is
problematic in warm-standby because restore_command can fail every
five seconds even while new WAL file is expected to be unavailable
for a long time and flood the log files with its error messages.
This commit adds new parameter, wal_retrieve_retry_interval, to
control that wait time. Alexey Vasiliev and Michael Paquier,
reviewed by Andres Freund and me.
http://git.postgresql.org/pg/commitdiff/5d2b45e3f78a85639f30431181c06d4c3221c5a1

- Add note about how to make the SRF detoasted arguments live accross
calls. Andrew Gierth and Ali Akbar
http://git.postgresql.org/pg/commitdiff/a7920b872fff36668a2d33157609024b851b5c2e

Andres Freund pushed:

- Guard against spurious signals in LockBufferForCleanup. When
LockBufferForCleanup() has to wait for getting a cleanup lock on a
buffer it does so by setting a flag in the buffer header and then
wait for other backends to signal it using ProcWaitForSignal().
Unfortunately LockBufferForCleanup() missed that ProcWaitForSignal()
can return for other reasons than the signal it is hoping for. If
such a spurious signal arrives the wait flags on the buffer header
will still be set. That then triggers "ERROR: multiple backends
attempting to wait for pincount 1". The fix is simple, unset the
flag if still set when retrying. That implies an additional spinlock
acquisition/release, but that's unlikely to matter given the cost of
waiting for a cleanup lock. Alternatively it'd have been possible
to move responsibility for maintaining the relevant flag to the
waiter all together, but that might have had negative consequences
due to possible floods of signals. Besides being more invasive.
This looks to be a very longstanding bug. The relevant code in
LockBufferForCleanup() hasn't changed materially since its
introduction and ProcWaitForSignal() was documented to return for
unrelated reasons since 8.2. The master only patch series removing
ImmediateInterruptOK made it much easier to hit though, as
ProcSendSignal/ProcWaitForSignal now uses a latch shared with other
tasks. Per discussion with Kevin Grittner, Tom Lane and me.
Backpatch to all supported branches. Discussion:
11553(dot)1423805224(at)sss(dot)pgh(dot)pa(dot)us
http://git.postgresql.org/pg/commitdiff/bc208a5a2f9eb34bf795374fa5381e0c82073255

- Reconsider when to wait for WAL flushes/syncrep during commit. Up
to now RecordTransactionCommit() waited for WAL to be flushed (if
synchronous_commit != off) and to be synchronously replicated (if
enabled), even if a transaction did not have a xid assigned. The
primary reason for that is that sequence's nextval() did not assign
a xid, but are worthwhile to wait for on commit. This can be
problematic because sometimes read only transactions do write WAL,
e.g. HOT page prune records. That then could lead to read only
transactions having to wait during commit. Not something people
expect in a read only transaction. This lead to such strange
symptoms as backends being seemingly stuck during connection
establishment when all synchronous replicas are down. Especially
annoying when said stuck connection is the standby trying to
reconnect to allow syncrep again... This behavior also is involved
in a rather complicated <= 9.4 bug where the transaction started by
catchup interrupt processing waited for syncrep using latches, but
didn't get the wakeup because it was already running inside the same
overloaded signal handler. Fix the issue here doesn't properly solve
that issue, merely papers over the problems. In 9.5 catchup
interrupts aren't processed out of signal handlers anymore. To fix
all this, make nextval() acquire a top level xid, and only wait for
transaction commit if a transaction both acquired a xid and emitted
WAL records. If only a xid has been assigned we don't uselessly
want to wait just because of writes to temporary/unlogged tables; if
only WAL has been written we don't want to wait just because of HOT
prunes. The xid assignment in nextval() is unlikely to cause
overhead in real-world workloads. For one it only happens
SEQ_LOG_VALS/32 values anyway, for another only usage of nextval()
without using the result in an insert or similar is affected.
Discussion: 20150223165359(dot)GF30784(at)awork2(dot)anarazel(dot)de,
369698E947874884A77849D8FE3680C2(at)maumau,
5CF4ABBA67674088B3941894E22A0D25(at)maumau Per complaint from maumau
and Thom Brown Backpatch all the way back; 9.0 doesn't have syncrep,
but it seems better to be consistent behavior across all maintained
branches.
http://git.postgresql.org/pg/commitdiff/fd6a3f3ad4067f1b8fc28e9de6e99e5936d82161

Tom Lane pushed:

- Further tweaking of raw grammar output to distinguish different
inputs. Use a different A_Expr_Kind for LIKE/ILIKE/SIMILAR TO
constructs, so that they can be distinguished from direct invocation
of the underlying operators. Also, postpone selection of the
operator name when transforming "x IN (select)" to "x = ANY
(select)", so that those syntaxes can be told apart at parse
analysis time. I had originally thought I'd also have to do
something special for the syntaxes IS NOT DISTINCT FROM, IS NOT
DOCUMENT, and x NOT IN (SELECT...), which the grammar translates as
though they were NOT (construct). On reflection though, we can
distinguish those cases reliably by noting whether the parse
location shown for the NOT is the same as for its child node. This
only requires tweaking the parse locations for NOT IN, which I've
done here. These changes should have no effect outside the parser;
they're just in support of being able to give accurate warnings for
planned operator precedence changes.
http://git.postgresql.org/pg/commitdiff/56be925e4b8f5b1c0e6716ca5cbe0360d1229f50

- Improve parser's one-extra-token lookahead mechanism. There are a
couple of places in our grammar that fail to be strict LALR(1), by
requiring more than a single token of lookahead to decide what to
do. Up to now we've dealt with that by using a filter between the
lexer and parser that merges adjacent tokens into one in the places
where two tokens of lookahead are necessary. But that creates a
number of user-visible anomalies, for instance that you can't name a
CTE "ordinality" because "WITH ordinality AS ..." triggers folding
of WITH and ORDINALITY into one token. I realized that there's a
better way. In this patch, we still do the lookahead basically as
before, but we never merge the second token into the first; we
replace just the first token by a special lookahead symbol when one
of the lookahead pairs is seen. This requires a couple extra
productions in the grammar, but it involves fewer special tokens, so
that the grammar tables come out a bit smaller than before. The
filter logic is no slower than before, perhaps a bit faster. I also
fixed the filter logic so that when backing up after a lookahead,
the current token's terminator is correctly restored; this
eliminates some weird behavior in error message issuance, as is
shown by the one change in existing regression test outputs. I
believe that this patch entirely eliminates odd behaviors caused by
lookahead for WITH. It doesn't really improve the situation for
NULLS followed by FIRST/LAST unfortunately: those sequences still
act like a reserved word, even though there are cases where they
should be seen as two ordinary identifiers, eg "SELECT nulls first
FROM ...". I experimented with additional grammar hacks but
couldn't find any simple solution for that. Still, this is better
than before, and it seems much more likely that we *could* somehow
solve the NULLS case on the basis of this filter behavior than the
previous one.
http://git.postgresql.org/pg/commitdiff/d809fd0008a2e26de463f47b7aba0365264078f3

- Fix dumping of views that are just VALUES(...) but have column
aliases. The "simple" path for printing VALUES clauses doesn't work
if we need to attach nondefault column aliases, because there's
noplace to do that in the minimal VALUES() syntax. So modify
get_simple_values_rte() to detect nondefault aliases and treat that
as a non-simple case. This further exposes that the "non-simple"
path never actually worked; it didn't produce valid syntax. Fix
that too. Per bug #12789 from Curtis McEnroe, and analysis by
Andrew Gierth. Back-patch to all supported branches. Before 9.3,
this also requires back-patching the part of commit
092d7ded29f36b0539046b23b81b9f0bf2d637f1 that created
get_simple_values_rte() to begin with; inserting the extra test into
the old factorization of that logic would've been too messy.
http://git.postgresql.org/pg/commitdiff/e9f1c01b71dcd11c86fc8516c06dae2e784b96fd

- Fix over-optimistic caching in fetch_array_arg_replace_nulls().
When I rewrote this in commit
56a79a869bedc4bf6c35853642694cc0b0594dd2, I forgot that it's
possible for the input array type to change from one call to the
next (this can happen when applying the function to pg_statistic
columns, for instance). Fix that.
http://git.postgresql.org/pg/commitdiff/77903ede08845e55bd2a6c99b52d8da6926d6e84

- Redefine MemoryContextReset() as deleting, not resetting, child
contexts. That is, MemoryContextReset() now means what was formerly
meant by MemoryContextResetAndDeleteChildren(), and the latter is
now just a macro alias for the former. If you really want the
functionality that was formerly provided by MemoryContextReset(),
what you have to do is MemoryContextResetChildren() plus
MemoryContextResetOnly() (which is a new API to reset *only* the
named context and not touch its children). The reason for this
change is that near fifteen years of experience has proven that
there is noplace where old-style MemoryContextReset() is actually
what you want. Making that the default behavior has led to lots of
context-leakage bugs, while we've not found anyplace where it's
actually necessary to keep the child contexts; at least the standard
regression tests do not reveal anyplace where this change breaks
anything. And there are upcoming patches that will introduce
additional reasons why child contexts need to be removed. We could
change existing calls of MemoryContextResetAndDeleteChildren to be
just MemoryContextReset, but for the moment I'll leave them alone;
they're not costing anything.
http://git.postgresql.org/pg/commitdiff/eaa5808e8ec4e82ce1a87103a6b6f687666e4e4c

- Suppress uninitialized-variable warning from less-bright compilers.
The type variable must get set on first iteration of the while loop,
but there are reasonably modern gcc versions that don't realize
that. Initialize it with a dummy value. This undoes a removal of
initialization in commit 654809e770ce270c0bb9de726c5df1ab193d60f0.
http://git.postgresql.org/pg/commitdiff/d61f1a93271b859938b6cdb301a367cdb8abf81c

- Improve mmgr README. Add documentation about the new reset callback
mechanism. Also, at long last, recast the existing text so that it
describes the current context mechanisms as established fact rather
than something we're going to implement. Shoulda done that in 2001
or so ...
http://git.postgresql.org/pg/commitdiff/c4f4c7ca99169ac609df67c2d0eb78162484420c

- Fix planning of star-schema-style queries. Part of the intent of
the parameterized-path mechanism was to handle star-schema queries
efficiently, but some overly-restrictive search limiting logic added
in commit e2fa76d80ba571d4de8992de6386536867250474 prevented such
cases from working as desired. Fix that and add a regression test
about it. Per gripe from Marc Cousin. This is arguably a bug
rather than a new feature, so back-patch to 9.2 where parameterized
paths were introduced.
http://git.postgresql.org/pg/commitdiff/b514a7460d9127ddda6598307272c701cbb133b7

- Track typmods in plpgsql expression evaluation and assignment. The
main value of this change is to avoid expensive I/O conversions when
assigning to a variable that has a typmod specification, if the
value to be assigned is already known to have the right typmod.
This is particularly valuable for arrays with typmod specifications;
formerly, in an assignment to an array element the entire array
would invariably get put through double I/O conversion to check the
typmod, to absolutely no purpose since we'd already properly coerced
the new element value. Extracted from my "expanded arrays" patch;
this seems worth committing separately, whatever becomes of that
patch, since it's really an independent issue. As long as we're
changing the function signatures, take the opportunity to
rationalize the argument lists of exec_assign_value,
exec_cast_value, and exec_simple_cast_value; that is, put the
arguments into a saner order, and get rid of the bizarre choice to
pass exec_assign_value's isNull flag by reference.
http://git.postgresql.org/pg/commitdiff/e524cbdc45ec6d677b1dd49ee64dd403959eda0f

- Invent a memory context reset/delete callback mechanism. This
allows cleanup actions to be registered to be called just before a
particular memory context's contents are flushed (either by deletion
or MemoryContextReset). The patch in itself has no use-cases for
this, but several likely reasons for wanting this exist. In
passing, per discussion, rearrange some boolean fields in struct
MemoryContextData so as to avoid wasted padding space. For safety,
this requires making allowInCritSection's existence unconditional;
but I think that's a better approach than what was there anyway.
http://git.postgresql.org/pg/commitdiff/f65e8270587f3e9b8224e20f7d020ed1f816dfe1

- Move memory context callback declarations into palloc.h. Initial
experience with this feature suggests that instances of
MemoryContextCallback are likely to propagate into some widely-used
headers over time. As things stood, that would result in pulling
memutils.h or at least memnodes.h into common headers, which does
not seem desirable. Instead, let's decide that this feature is part
of the "ordinary palloc user" API rather than the "specialized
context management" API, and as such should be declared in palloc.h
not memutils.h.
http://git.postgresql.org/pg/commitdiff/097fe194aa7c590b4fa43d5e40c083940859c286

- Use the typcache to cache constraints for domain types. Previously,
we cached domain constraints for the life of a query, or really for
the life of the FmgrInfo struct that was used to invoke domain_in()
or domain_check(). But plpgsql (and probably other places) are set
up to cache such FmgrInfos for the whole lifespan of a session,
which meant they could be enforcing really stale sets of
constraints. On the other hand, searching pg_constraint once per
query gets kind of expensive too: testing says that as much as half
the runtime of a trivial query such as "SELECT 0::domaintype" went
into that. To fix this, delegate the responsibility for tracking a
domain's constraints to the typcache, which has the infrastructure
needed to detect syscache invalidation events that signal possible
changes. This not only removes unnecessary repeat reads of
pg_constraint, but ensures that we never apply stale constraint
data: whatever we use is the current data according to syscache
rules. Unfortunately, the current configuration of the system
catalogs means we have to flush cached domain-constraint data
whenever either pg_type or pg_constraint changes, which happens
rather a lot (eg, creation or deletion of a temp table will do it).
It might be worth rearranging things to split pg_constraint into two
catalogs, of which the domain constraint one would probably be very
low-traffic. That's a job for another patch though, and in any case
this patch should improve matters materially even with that
handicap. This patch makes use of the recently-added memory context
reset callback feature to manage the lifespan of domain constraint
caches, so that we don't risk deleting a cache that might be in the
midst of evaluation. Although this is a bug fix as well as a
performance improvement, no back-patch. There haven't been many if
any field complaints about stale domain constraint checks, so it
doesn't seem worth taking the risk of modifying data structures as
basic as MemoryContexts in back branches.
http://git.postgresql.org/pg/commitdiff/8abb3cda0ddc00a0ab98977a1633a95b97068d4e

Álvaro Herrera pushed:

- Fix stupid merge errors in previous commit. Brown paper bag
installed permanently.
http://git.postgresql.org/pg/commitdiff/d1712d01d01d2c14355fad497fa7a6ae6e33694f

- Support more commands in event triggers. COMMENT, SECURITY LABEL,
and GRANT/REVOKE now also fire ddl_command_start and ddl_command_end
event triggers, when they operate on database-local objects.
Reviewed-By: Michael Paquier, Andres Freund, Stephen Frost
http://git.postgresql.org/pg/commitdiff/296f3a6053844089bc533630fffafaba8f016384

- Fix table_rewrite event trigger for ALTER TYPE/SET DATA TYPE
CASCADE. When a composite type being used in a typed table is
modified by way of ALTER TYPE, a table rewrite occurs appearing to
come from ALTER TYPE. The existing event_trigger.c code was unable
to cope with that and raised a spurious error. The fix is just to
accept that command tag for the event, and document this properly.
Noted while fooling with deparsing of DDL commands. This appears to
be an oversight in commit 618c9430a. Thanks to Mark Wong for
documentation wording help.
http://git.postgresql.org/pg/commitdiff/3f190f67eb45ae61d696fbce8ab48d246a12f709

- Make CREATE OR REPLACE VIEW internally more consistent. The way
that columns are added to a view is by calling AlterTableInternal
with special subtype AT_AddColumnToView; but that subtype is changed
to AT_AddColumnRecurse by ATPrepAddColumn. This has no visible
effect in the current code, since views cannot have inheritance
children (thus the recursion step is a no-op) and adding a column to
a view is executed identically to doing it to a table; but it does
make a difference for future event trigger code keeping track of
commands, because the current situation leads to confusing the case
with a normal ALTER TABLE ADD COLUMN. Fix the problem by passing a
flag to ATPrepAddColumn to prevent it from changing the command
subtype. The event trigger code can then properly ignore the
subcommand. (We could remove the call to ATPrepAddColumn, since
views are never typed, and there is never a need for recursion,
which are the two conditions that are checked by ATPrepAddColumn;
but it seems more future-proof to keep the call in place.)
http://git.postgresql.org/pg/commitdiff/fbef4342a86522c98cd605891ad8c1145a61d191

- Fix a couple of trivial issues in jsonb.c. Typo "aggreagate"
appeared three times, and the return value of function
JsonbIteratorNext() was being assigned to an int variable in a bunch
of places.
http://git.postgresql.org/pg/commitdiff/654809e770ce270c0bb9de726c5df1ab193d60f0

- Fix intermittent failure in event_trigger test. As evidenced by
measles in buildfarm. Pointed out by Tom Lane.
http://git.postgresql.org/pg/commitdiff/e059e02e43cd825616192d010e9e638a96ad4717

Peter Eisentraut pushed:

- Fix invalid DocBook XML
http://git.postgresql.org/pg/commitdiff/b007bee1f6962ad1007056f64b9eb2e505fa6806

- Error when creating names too long for tar format The tar format (at
least the version we are using), does not support file names or
symlink targets longer than 99 bytes. Until now, the tar creation
code would silently truncate any names that are too long. (Its
original application was pg_dump, where this never happens.) This
creates problems when running base backups over the replication
protocol. The most important problem is when a tablespace path is
longer than 99 bytes, which will result in a truncated tablespace
path being backed up. Less importantly, the basebackup protocol
also promises to back up any other files it happens to find in the
data directory, which would also lead to file name truncation if
someone put a file with a long name in there. Now both of these
cases result in an error during the backup. Add tests that fail
when a too-long file name or symlink is attempted to be backed up.
Reviewed-by: Robert Haas <robertmhaas(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/23a78352c0a0dc21d6120bd868f0b2d07395b537

Michael Meskes pushed:

- Remove null-pointer checks that are not needed. If a pointer is
guaranteed to carry information there is no need to check for NULL
again. Patch by Michael Paquier.
http://git.postgresql.org/pg/commitdiff/8794bf1ca164e1be1554197b46c9ffc62d162fb8

Stephen Frost pushed:

- Add locking clause for SB views for update/delete. In
expand_security_qual(), we were handling locking correctly when a
PlanRowMark existed, but not when we were working with the target
relation (which doesn't have any PlanRowMarks, but the subquery
created for the security barrier quals still needs to lock the rows
under it). Noted by Etsuro Fujita when working with the Postgres
FDW, which wasn't properly issuing a SELECT ... FOR UPDATE to the
remote side under a DELETE. Back-patch to 9.4 where updatable
security barrier views were introduced. Per discussion with Etsuro
Fujita and Dean Rasheed.
http://git.postgresql.org/pg/commitdiff/6f9bd50eabb0a4960e94c83dac8855771c9f340d

- Add hasRowSecurity to copyfuncs/outfuncs. The RLS patch added a
hasRowSecurity field to PlannerGlobal and PlannedStmt but didn't
update nodes/copyfuncs.c and nodes/outfuncs.c to reflect those
additional fields. Correct that by adding entries to the
appropriate functions for those fields. Pointed out by Robert Haas.
http://git.postgresql.org/pg/commitdiff/62a4a1af5d1d84f0023bc3816c204191b0f4f49f

- Fix targetRelation initializiation in prepsecurity. In
6f9bd50eabb0a4960e94c83dac8855771c9f340d, we modified
expand_security_quals() to tell expand_security_qual() about when
the current RTE was the targetRelation. Unfortunately, that commit
initialized the targetRelation variable used outside of the loop
over the RTEs instead of at the start of it. This patch moves the
variable and the initialization of it into the loop, where it should
have been to begin with. Pointed out by Dean Rasheed. Back-patch
to 9.4 as the original commit was.
http://git.postgresql.org/pg/commitdiff/ee4ddcb38a0abfdb8f7302bbc332a1cb92888ed1

Noah Misch pushed:

- Free SQLSTATE and SQLERRM no earlier than other PL/pgSQL variables.
"RETURN SQLERRM" prompted plpgsql_exec_function() to read from freed
memory. Back-patch to 9.0 (all supported versions). Little code
ran between the premature free and the read, so non-assert builds
are unlikely to witness user-visible consequences.
http://git.postgresql.org/pg/commitdiff/f5ef00aed4c39645716cabb2e4cf1ef3598fcde7

- Unlink static libraries before rebuilding them. When the library
already exists in the build directory, "ar" preserves members not
named on its command line. This mattered when, for example, a
"configure" rerun dropped a file from $(LIBOBJS). libpgport carried
the obsolete member until "make clean". Back-patch to 9.0 (all
supported versions).
http://git.postgresql.org/pg/commitdiff/424793fa5dc631254f69d5ee8d7d7d6de2976f60

- Add transform functions for AT TIME ZONE. This makes "ALTER TABLE
tabname ALTER tscol TYPE ... USING tscol AT TIME ZONE 'UTC'" skip
rewriting the table when altering from "timestamp" to "timestamptz"
or vice versa. While it would be nicer still to optimize this in
the absence of the USING clause given timezone==UTC, transform
functions must consult IMMUTABLE facts only.
http://git.postgresql.org/pg/commitdiff/b8a18ad4850ea5ad7884aa6ab731fd392e73b4ad

Andrew Dunstan pushed:

- Render infinite date/timestamps as 'infinity' for json/jsonb.
Commit ab14a73a6c raised an error in these cases and later the
behaviour was copied to jsonb. This is what the XML code, which we
then adopted, does, as the XSD types don't accept infinite values.
However, json dates and timestamps are just strings as far as json
is concerned, so there is no reason not to render these values as
'infinity'. The json portion of this is backpatched to 9.4 where
the behaviour was introduced. The jsonb portion only affects the
development branch. Per gripe on pgsql-general.
http://git.postgresql.org/pg/commitdiff/bda76c1c8cfb1d11751ba6be88f0242850481733

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Corey Huinker sent in another revision of a patch to add polymorphic
functions to dblink.

Tom Lane sent in two more revisions of a patch to make operator
precedent standards compliant and sane.

Michael Paquier sent in two more revisions of a patch to enforce
creation of input and output paths in pg_regress, and add
regress_dynamic as a test module.

David Steele sent in two more revisions of a patch to add pg_audit as
an extension.

Álvaro Herrera sent in a patch to remove the OBJECT_ATTRIBUTE symbol.

Peter Eisentraut sent in another revision of a patch to add logical
decoding support for ON CONFLICT UPDATE.

Andres Freund sent in a patch to reconsider when to flush WAL and wait
for syncrep while committing.

Rahila Syed sent in three more revisions of a patch to compress
full-page writes.

Álvaro Herrera and David Fetter traded patches to fix a bug in psql's
handling of connect strings and URIs in psql's \connect.

Tomas Vondra sent in another revision of a patch to separate logical
from physical column ordering.

Michael Paquier and Stephen Frost traded patches to fix a dependency
issue in pg_dump which mis-ordered tables in extensions.

Kyotaro HORIGUCHI sent in another revision of a patch to ensure that
pg_basebackup sends feedback regularly, even under heavy loads.

Tom Lane sent in a patch to ensure that NOT LIKE, etc., have
reasonable precedence.

Andreas Karlsson sent in a patch to fix some autoconf deprecation
warnings.

Amit Langote sent in two revisions of a patch to implement native
partitioning.

Álvaro Herrera sent in two flocks of patches for deparsing utility
commands.

Alexander Korotkov sent in another revision of a patch to add KNN-GiST
with recheck.

Michael Paquier sent in a patch to add NULL-pointer check and
incorrect comment for pstate in addRangeTableEntry.

Fabien COELHO sent in two more revisions of a patch to add more tests
on event triggers.

Tom Lane sent in another revision of a patch to manipulate complex
types as non-contiguous structures in-memory.

Fabrízio de Royes Mello sent in a patch to add CINE for ALTER TABLE
... ADD COLUMN.

Kyotaro HORIGUCHI sent in another revision of a patch to add new OID
alias type regrole.

Tom Lane sent in a patch to make MemoryContextReset delete children.

Tom Lane sent in a patch to add MemoryContext reset/delete callbacks.

Haribabu Kommi sent in another revision of a patch to provide a
catalog view to the pg_hba.conf file.

Kyotaro HORIGUCHI and Kevin Grittner traded patches to reduce pinning
in btree indexes.

Corey Huinker sent in another revision of a patch to allow FETCH
limited by bytes.

Anastasia Lubennikova and Heikki Linnakangas traded patches to add
index-only scans for GiST.

Michael Paquier sent in a patch to rm static libraries before
rebuilding.

Stephen Frost sent in another revision of a patch to add role
attributes for various operations.

Tom Lane sent in a patch to cache domain constraints properly.

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

Andrew Dunstan sent in another revision of a patch to implement
mogrify and indent features for jsonb.