jsonb is coming up with a set of new features in Postgres 9.5. Most of them have been introduced by the following commit:

After seeing an email on [pgsql-general] (https://www.postgresql.org/message-id/CANkGpBs7qgAkgQ-OPZY0EsaM6+WUE5MgpyeHCGo_eOQ7tJVyyg@mail.gmail.com) about a user willing to be able to archive WAL from a standby to store them locally and to save bandwidth by only receiving the WAL segments through a WAL stream, let’s talk about a new feature of Postgres 9.5 that will introduce exactly what this user was looking for, as known as being able to archive WAL from a standby to have more complicated archiving strategies. This feature has been introduced by this commit:

Today’s highlight is about a new system view that will land in Postgres 9.5, that has been introduced by this commit:

Postgres 9.5 is bringing a change in the way WAL is archived with the following commit:

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: