A couple of days back the following commit has landed in the Postgres world, for the upcoming 9.5 release:

Marked as the number #1 wanted feature in Postgres that has been missing for years by many people, upsert support has landed in the Postgres world and will be released with the upcoming 9.5:

On Unix-Linux platforms, Postgres binaries are not authorized to run as root use for security reasons when those utilities directly manipulate files in the data directory. See for example initdb:

Similarly to the post of a couple of weeks back relating about the [new memory allocation routine] (/postgresql-2/postgres-9-5-feature-highlight-allocation-routine-no-oom/) able to give a plan B route in case of OOM, here is a follow-up commit adding more infrastructure in the same area but this time for some widely-used memory allocation routines:

[log_autovacuum_min_duration] (https://www.postgresql.org/docs/devel/static/runtime-config-autovacuum.html#GUC-LOG-AUTOVACUUM-MIN-DURATION) is a system-wide parameter controlling a threshold from which autovacuum activity is logged in the system logs. Every person who has already worked on looking at a system where a given set of table is bloated has for sure already been annoyed by the fact that even a high value of log_autovacuum_min_duration offers no guarantee in reducing log spams of not-much-bloated tables whose autovacuum runtime takes more than the threshold value, making its activity being logged (and this is after working on such a lambda system that the author of this feature wrote a patch for it). Postgres 9.5 is coming with a new feature allowing to control this logging threshold at relation level, feature introduced by this commit:

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: