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.

Just to make people aware of it, the following commit has reached the Postgres land a couple of days ago in all the active branches of the project, down to 9.1:

Since its introduction in 9.1, [synchronous replication] (https://www.postgresql.org/docs/devel/static/warm-standby.html#SYNCHRONOUS-REPLICATION), or the ability to wait for a WAL flush confirmation from a standby before committing a transaction on the master node (depends on synchronous_commit whose default value is on), ensuring that the transaction committed has not been lost on the standby should a failover need to be done, has faced a wide adoption in many production environments for applications that need a no-data-loss scenario. Still, such application or clients may have seen something like that:

Today, here is some highlight about a small feature that will available in Postgres 9.6, useful for application and monitoring purposes:

The set of [file access functions] (https://www.postgresql.org/docs/devel/static/functions-admin.html#FUNCTIONS-ADMIN-GENFILE) already present in PostgreSQL offer no direct possibility to retrieve file system information, giving for example no coverage of how a file system is behaving while running a given PostgreSQL instance. Modern platforms offer usually the Posix system call statvfs, that allows to retrieve this information. However, there is no direct equivalent on Windows, making the chance to have an in-core feature available depend on what are the equivalent things available statvfs for Windows, which may become ugly because this would require at quick glance the use of multiple low-level functions like for example GetDiskFreeSpaceExW to get the amount of free space available in a given path. At least that would be less elegant than calling simply statvfs.

ALTER TABLE has been known for many years in the Postgres ecosystem as being a command taking systematically an ACCESS EXCLUSIVE lock on the relation being modified, preventing all operations on the relation in parallel. Those locks are getting more and more relaxed, with for example in Postgres 9.4 the following commands that got improvements:

Today here are highlights about new features regarding replication slots that have been lately committed and will be present as part of PostgreSQL 9.6:

Since PostgreSQL 9.3, the code tree is shipping a file named xlogreader.c that contains a set of independent routines that can be used to read and decode WAL records. While it is not available in an independent library, any frontend or backend application can use it at compilation to be able to work on WAL. The code of PostgreSQL uses it already in a couple of places, hence many examples are already available in core to help the development of plugins with this facility: