In the previous blog post we have seen how plenty of ram doesn’t necessary results in a faster instance.
This time we’ll quickly see how PostgreSQL and Linux relate to each other in particular if we want to run our RDBMS at scale.
Then we’ll have a look to the virtual memory in Linux and how to make it more friendly to PostgreSQL.
Let’s dig in.
Nowadays it’s not uncommon to deal with machines with hundreds of GB of RAM.
Abundant memory can give PostgreSQL a massive performance boost. However things work slightly different than you may expect.
Let’s find out!
For obvious reason the FOSDEM this year is an online event. The staff is building from scratch an infrastructure in order to deliver the speaker’s videos in a virtual environment.
The catch is that all the talks must be pre recorded and uploaded via pentabarf, the software historically used by FOSDEM to manage the talk submissions.
What follows is my experience in recording,uploading and submitting the video for my upcoming talk.
When in a pl/pgsql function there is an exception then the function stops the execution and returns an error. When this happens all the changes made are rolled back.
It’s always possible to manage the error at application level, however there are some cases where managing the exception inside the function it may be a sensible choice. And pl/pgsql have a nice way to do that. The EXCEPTION block.
However handling the exception inside a function is not just a cosmetic thing. The way the excepion is handled have implications that may cause issues.
Mistakes may happen and safeguards against human errors are always a good thing, even if they may seem annoying.
Back in 2002 a sysadmin posted on Usenet the story of a clueless user which by mistake dropped a vital table in the database. The story is part of a series known as Tales from the machine room and still available here (in Italian).
Let’s be clear, there’s nothing wrong in dropping stuff, if we drop the stuff that should be dropped. Otherwise we will get a one way ticket to a lot of trouble.
With PostgreSQL 12 the generated columns are now supported natively. Until the version Postgresql 11 it were possible to have generated columns using a trigger.
In this post we’ll see how to configure a generated column via trigger and natively then we’ll compare the performances of both strategies.
The transactional model has been in PostgreSQL since the early versions. In PostgreSQL its implementation follows the guidelines of the SQL standard with some notable exceptions.
When designing an application it’s important to understand how the concurrent access to data happens in order to avoid unexpected results or even errors.
In the previous post we modified the apt role for controlling the setup in a declarative way. Then we added a ssh role for configuring the three devuan servers. The role is used to configure the server’s postgres process owner for ssh passwordless connection.
In this tutorial we’ll complete the setup for the postgres user and then we’ll configure the database clusters with a new role.
