pg_receivexlog is an in-core utility of Postgres able to recover WAL files through a stream using the replication protocol. It is particularly useful when for example using it to transfer some WAL files to a proxy node when standby node cannot connect directly to a root node for whatever reason. The standby can then replay the WAL files obtained. The reliability of this utility has been improved in Postgres 9.5 with the following commit:

Postgres has in-core support for [Dynamic tracing] (https://www.postgresql.org/docs/devel/static/dynamic-trace.html), which is the possibility to use an external utility to track specific code path calls and have an execution trace at disposition for further analysis. Enabling this feature can be done when compiling code by specifying –enable-dtrace at [configure] (https://www.postgresql.org/docs/devel/static/install-procedure.html) step. Note as well that on Linux systems you will need systemtap installed (development package for compilation may be needed depending on your platform) to be able to compile code with this support, and extra kernel-level packages like kernel-devel to be able to take traces. In order to check if your installation is able to do dynamic tracing, for example simply run the following “Hello World” command.

Postgres 9.5 is coming up with a new ECHO mode for [psql] (https://www.postgresql.org/docs/devel/static/app-psql.html) that has been introduced by this commit:

[IMPORT FOREIGN SCHEMA] (https://www.postgresql.org/docs/devel/static/sql-importforeignschema.html) is a SQL query defined in the SQL specification allowing to import from a foreign source a schema made of foreign tables. Its support has been added in Postgres 9.5 with the following commit:

Postgres 9.5 is going to improve the performance of subqueries using window functions by allowing the pushdown of WHERE clauses within them. Here is a commit, done during commit fest 1, that is the origin of this improvement:

Here is a small feature that has showed up during the [first commit fest] (https://commitfest.postgresql.org/action/commitfest_view?id=22) of Postgres 9.5 allowing to add complementary information in the process names displayed by a server:

The [jsonb datatype] (https://www.postgresql.org/docs/devel/static/datatype-json.html) newly introduced in Postgres 9.4 has a property that makes its manipulation rather facilitate when doing operations on it with embedded functions: it does not allow duplicated object keys. On the contrary, json allows that as you can see here:

Postgres 9.4 is adding a new in-core GiST operator class for the [inet and cidr] (https://www.postgresql.org/docs/9.4/static/datatype-net-types.html#DATATYPE-INET) datatypes. It has been introduced by this commit:

Working with logical replication and a cluster of nodes heavily linked among each other can result in particularly disturbing results. If a logical change is received on a node that itself regenerates additional changes, it is really easy to finish with an uncontrolable chain reaction.

These last couple of days I have been developing for studies a background worker able to fetch changes from a logical decoder already developed and presented on this blog called [decoder_raw] (https://github.com/michaelpq/pg_plugins/tree/master/decoder_raw) able to generate raw queries based on the logical changes decoded on server from its WAL. This receiver, called [receiver_raw] (https://github.com/michaelpq/pg_plugins/tree/master/receiver_raw) runs as a background worker that connects to a node running decoder_raw using a replication connection and then fetches decoded logical changes from it, which are in this case ready-to-be-applied raw queries. Those changes are then applied on the database one by one using the [SPI] (https://www.postgresql.org/docs/devel/static/spi.html) through a loop process that sleeps during a customizable amount of nap time. Note that receiver_raw is actually designed to be performant as it applies one single batch of changes using only one transaction in a single loop process. That’s the best doable particularly for long transactions.