The addition of SCRAM-SHA-256 is proving to have many benefits in PostgreSQL over MD5, but it has required an extension of the authentication protocol so as message exchanges for SASL authentication are able to work correctly. A lot of details on this matter are defined in the documentation:

Postgres 10 will be released in a couple of months, with its beta 1 to be out very soon, and for this release many small, incompatible changes have been introduced during its development to help with long-term maintenance. The full list of items is present in the release notes, and here are the changes that can have an impact on any applications relying of what PostgreSQL has provided up to now.

An important step in the SCRAM authentication is called SASLprep, a mandatory feature to be sure about the equivalence of two strings encoded with UTF-8. A first commit has added support for SCRAM-SHA-256 protocol with the full SASL exchange plugged on top of it, and this has been implemented by the following commit:

The following feature has landed in Postgres 10 to help system administrators:

Password are hashed by default in PostgreSQL using MD5, more and more voices show up to mention that this is bad, particularly because it is possible to log into a server by just knowing the contents of pg_authid or find out about those hashes in past backups still lying around. Normally this data cannot be reached except by superusers, but things leaking sometimes, using MD5 can prove to be insecure in some cases (even if MD5 is strong against pre-image attacks for example). Postgres 10 is adding a new authentication protocol with the following commit:

Here is a feature for Postgres 10 that a couple of people will find useful regarding the handling of password files:

Last week the following commit has landed in Postgres 10 code tree, something that many users of servers with complicated connection policies will find useful:

One of my personal areas of work lately is in finding ways to improve the user experience with WAL archiving and pg_receivexlog. A couple of experiments have been done, and one of them has finished as a patch for upstream Postgres, in the shape of this commit:

Here are some news from the front of Postgres 10 development, with the highlight of the following commit:

Today’s post, the first one of 2017, is about the following feature of the upcoming Postgres 10: