PostgreSQL has gained two features that help in getting information about the memory usage of sessions. First, as of this commit, there is one new system view that reports the memory usage for a session:

The following feature has been committed into PostgreSQL 14, as of this commit:

PostgreSQL has a long history with cryptographic hashes, coming into three parts, roughly. First, MD5 authentication, that exists in PostgreSQL since 2001 in this commit. This feature has come up with its own implementation of this hash in either src/common/md5.c or src/backend/libpq/md5.c, depending on the branch of the code checked out. This is then used by libpq or the backend code. One thing to know is that this code gets used even when building PostgreSQL with OpenSSL, library that has its own APIs to be able to build MD5 hashes.

It has been some time since something has been posted on this blog, and here is a short story about the following commit, for a feature that will land in the upcoming version 14 of PostgreSQL:

Replication slots can be used in streaming replication, with physical replication slots, and logical decoding, with logical replication slots, to retain WAL in a more precise way than wal_keep_segments so as past WAL segments are removed at checkpoint using the WAL position a client consuming the slot sees fit. A feature related to replication slots has been committed to PostgreSQL 12:

PostgreSQL 12 has changed the way recovery configuration works, and has introduced a couple of incompatible issues as mentioned in the main commit which has done the switch:

Since Postgres 11, it is possible to monitor progress activity of running manual VACUUM and even autovacuum using a dedicated system catalog called pg_stat_progress_vacuum. This is vital for operators when doing some long-running operations, because it is possible to not blindly wait for an operation to finish. When doing performance workload analysis, this is also proving to be helpful in evaluating VACUUM job progressing for tuning system-level parameters or even relation-level once depending on the load pattern.

Postgres ships in-core data types for JSON with specific functions and operators (json since 9.2, and jsonb which is a binary representation since 9.4). The upcoming Postgres 12 is becoming more compliant with the SQL specifications by introducing SQL/JSON path language, introduced mainly by the following commit:

Postgres is very nice when it comes to extending with custom plugins, with many set of facilities available, like:

A lot of work has been put into making Postgres 12 an excellent release to come, and in some of the features introduced, there is one which found its way into the tree and has been first proposed to community at the end of 2012. Here is the commit which has introduced it: