ACID

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.

Back in the days of when I was an Oracle DBA I had to solve a strange behaviour on an Oracle installation. The system for some reasons stopped accepting the writes occasionally and without an apparent reason. This behaviour appeared odd to anybody except for my team, which addressed the issue immediately. The problem was caused by a not optimal configuration on the Oracle instance. This thought led me to writing this post.