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.

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: