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:

As the first post dedicated to the feature coverage of Postgres 9.6 which is currently in active development, let’s talk about the following commit:

Docker is well-known, is used everywhere, is used by everybody and is a nice piece of technology, there is nothing to say about that.

PostgreSQL 9.5 is coming up with a new feature aimed at simplifying tracking of GUC parameters when those are set in a multiple set of files by introducing a new system view called pg_file_settings:

Finding its origin as a fix for [pg_rewind] (https://www.postgresql.org/docs/devel/static/app-pgrewind.html) where rewind process could fail if a file marked as listed in the source server was removed before fetching its data (see more details here, this could impact temporary files or relation file for example), here is a small feature of PostgreSQL 9.5 that may be useful for application developers: