One feature added in Postgres 9.6 is the WAL generic interface, which is a base for more fancy things like custom access methods. Note that custom access methods are quite powerful in themselves as they allow the development of for example custom index methods as external modules. The generic WAL records have been added primarily as the infrastructure to provide reliability to the custom access methods by allowing them to create WAL records. This has been introduced by the following commit:

pg_rewind, a utility introduced in PostgreSQL 9.5 allowing one to reconnect a master to one of its promoted standbys, making unnecessary the need of a new base backup and hence saving a huge amount of time, has gained something new in Postgres 9.6 with the following commit:

Among the features that are going to land with Postgres 9.6, here is a nice one that is going to make users in charge of high-availability structures quite happy, in short a lot:

While the last commit fest of PostgreSQL 9.6 is moving to an end with a soon-to-come feature freeze, here is a short story about one of the features that got committed close to the end of it:

Following the recent post related to the extension that gives a representation of a WAL receiver doing WAL recovery via streaming, here is its equivalent in-core, for a new feature that will be available in Postgres 9.6:

In the series of extensions making the life of operators and DBAs easier, and after the facility to easy the tracking of Postgres backend processes waiting for synchronous replication, here is a new feature that has been added to the existing module pg_rep_state aimed at representing at SQL level what shared memory holds for a WAL receiver (a WAL receiver being what is used on a backend receiving WAL in replication from a root node via streaming).

A new set of queries that can be handled in [COPY] (https://www.postgresql.org/docs/devel/static/sql-copy.html) statement (as well as psql’s \copy) has been added in PostgreSQL 9.6 by the following commit:

The following commit has popped up not so long ago in the development branch of Postgres 9.6:

PostgreSQL is a piece of software known for its robustness, being something reliable on which a complete infrastructure can be based to allow availability, reliability and performance. However, sometimes things can go wrong, there may be file-system or OS problems popping up, potentially corrupting a database and forcing one to roll in a backup or to perform a failover to another node. Sometimes, when studying the stability of a system, QE/QA procedures involve making one piece or more of an infrastructure unstable to test how other components can react to a failure and see if they can properly recover from it.

Just after the last set of minor versions of Postgres has been released, the following commit has popped up on all the stable branches to improve a long-time weird behavior of pg_ctl start.