Neues vom PostgreSQL Planet
This post is about a new PostgreSQL connection pooler that I came across recently: pgcat, which provides some useful features that I have not seen with the other poolers. Please mind the pgcat connection pooler is in beta, and they actually are looking for beta testers! If you are interested, read the pgcat beta test announcement/request.
It’s official! PostgreSQL 15 is out, and the community is abuzz discussing all the new features of the fresh release.
Meanwhile, the October CommitFest for PostgreSQL 16 had come and gone, with its own notable additions to the code.
If you missed the July CommitFest, our previous article will get you up to speed in no time.
Here are the patches I want to talk about:
The PostGIS development team is pleased to provide security, bug fixes and performance enhancements 3.3.2, 3.2.4, 3.1.8 and 3.0.8 for the 3.3, 3.2, 3.1, and 3.0 stable branches.
This time for sure (h/t Bullwinkle)
The PostGIS Team is pleased to release PostGIS 2.5.9! This is the end-of-life release of the 2.5 branch.
The last release of PostgreSQL 10 took place on Nov 10, 2022. While there are many articles on the new and exciting features in PostgreSQL, I thought this would be a good time to reflect on the impact of PostgreSQL 10.
PostgreSQL 10 had a lot of firsts. It was the first PostgreSQL release to have the two digit numbering scheme (PostgreSQL 10 vs. PostgreSQL 9.6). It was the first release with logical replication, declarative partitioning, and SCRAM.
In the first part of the article, we discussed how to achieve minimum security by adding a username and password to Patroni REST API and switching from HTTP traffic to HTTPS. In this article, we will be covering how to secure REST APIs using certificate authentication.
Certificate authentication is the only option if we want to prevent everyone else from accessing the “Safe” endpoints, which otherwise don’t require any credentials.
Shaun M. Thomas: Listening to Postgres: How LISTEN and NOTIFY Syntax Promote High Availability at the Application Layer
The original idea behind relational databases was "structure, then data": you needed to define what the data looked like before being able to insert any content. This strict data structure definition helped keeping datasets in order by verifying data types, referential integrity, and additional business conditions using dedicated constraints.
Rewriting OR is not always the best solution
© Laurenz Albe 2022
This blogpost is about a memory optimization that is applied to YugabyteDB version 18.104.22.168 that we applied that can make a huge difference in common situations with large amounts of memory allocated to multiple backends.
I laid the groundwork for investigating PostgreSQL and YugabyteDB here.
This is a further investigation, and some additional remarks.
It’s time again for the another PGSQL Phriday, this time, the question has been asked: How do you do PostgreSQL backups? Honesty up front. I’m very much just beginning my journey of learning PostgreSQL. I’ve been documenting that learning over here at Simple-Talk (more on the way there), including backups. For this post, I’m not […]
This is an introduction to the hypopg PostgreSQL extension for YugabyteDB 22.214.171.124. Hypopg allows the creation of hypothetical indexes, so indexes that do not really exist. This means this allows you to see what an index would do if it were created, without it actually being created, and therefore not influencing anything on the database. YugabyteDB 126.96.36.199 is a preview version of the YugabyteDB database.
The description from the documentation: