ads' corner

PostgreSQL uses Multi-Version Concurrency Control (MVCC) to manage concurrent access to the database, and store each version of a tuple in a table. To keep the database efficient, PostgreSQL employs a cleanup process called VACUUM, which removes unnecessary tuples. This not only saves disk space and keeps the database size under control, it also prevents the dreaded 'Transaction ID Wraparound' issue. Regularly running VACUUM is crucial, including on the template0 database, which is normally handled by the Autovacuum daemon. However, sometimes manual intervention is necessary.

Jens Kubieziel recently posted a Twitter poll: 2 + 2 * 4

While attending a conference (yay) the discussion turned to system columns, and especially 'ctid'. This was in context of backups, and the physical position of data on disk. The question was if that can be used to determine if an incremental backup is required, and if it is enough to just copy that field where the 'ctid' points to. Not quite, but I’d like to use this question to describe the system columns more in detail.

A couple days ago Devrim forked PostgreSQL to get a beer. That effort is of course laudable, but a bit extreme. PostgreSQL is very extensible, and allows to implement a beer now clock with just a few easy steps.

Christophe Pettus posted an interesting challenge. Two strings which on the surface look equal, but if you ask PostgreSQL to compare them, they are not equal.