This week, I wanted to share something that may impact many users of Postgres, with this commit changing a behavior in a binary utility that had for a long time been the same default:

This week the following commit has landed in PostgreSQL code tree, introducing a new feature that will be released in 9.5:

A nice feature extending the usage of [pgbench] (https://www.postgresql.org/docs/devel/static/pgbench.html), in-core tool of Postgres aimed at doing benchmarks, has landed in 9.5 with this commit:

In Postgres, [full-page writes] (https://www.postgresql.org/docs/devel/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS). which are in short complete images of a page added in WAL after the first modification of this page after a checkpoint, can be an origin of WAL bloat for applications manipulating many relation pages. Note that full-page writes are critical to ensure data consistency in case particularly if a crash happens during a page write, making perhaps this page made of both new and old data.

When working on testing WAL compression, I developed a simple hack able to calculate the amount of CPU used by a single Postgres backend process during its lifetime using getrusage invoked at process startup and shutdown. This thing is not aimed for an integration into core, still it may be useful for people who need to measure the amount of CPU used for a given set of SQL queries when working on a patch. Here is the patch, with no more than 20 lines:

The last months have showed a couple of vulnerabilities in openssl, so sometimes it is handy to get a status of how SSL is used on a given instance. For this purpose, there is a nice tool called sslyze that can help scanning SSL usage on a given server and it happens that it has support for the SSLrequest handshake that PostgreSQL embeds in its protocol (see [here] (https://www.postgresql.org/docs/devel/static/protocol-flow.html) regarding the message SSLrequest for more details).

Up to Postgres 9.4, when a node in recovery checks for the availability of WAL from a source, be it a WAL stream, WAL archive or local pg_xlog and that it fails to obtain what it wanted, it has to wait for a mount of 5s, amount of time hardcoded directly in xlog.c. 9.5 brings more flexibility with a built-in parameter allowing to control this interval of time thanks to this commit:

Not later than this week a bug regarding [pg_dump] (https://www.postgresql.org/docs/devel/static/app-pgdump.html) and compression with zlib when dumping data has been reported [here] (https://www.postgresql.org/message-id/20150217153446.2590.24945@wrigleys.postgresql.org).

As a preparation of an upcoming patch for full-page write compression in WAL, a patch has been pushed this week to make PGLZ, the in-core compression algorithm of PostgreSQL used for TOAST tables, more pluggable for plugins and frontend applications, particularly pg_xlogdump that needs to be able to decode a WAL record using the XLOG reader facility even if blocks are compressed to be able to reconstitute them. It makes as well sense to expose this algorithm as PGLZ compressed data would not be limited only to the internal backend usage of TOAST tables in a PostgreSQL instance, but as well to WAL data, be it simple WAL archive or a WAL streaming flow. So, here is the commit:

A couple of days ago the following commit has popped up in PostgreSQL tree for the upcoming 9.5, introducing a feature particularly interesting for developers of backend extensions and plugins: