ads' corner

How long will a 64 bit Transaction-ID last in PostgreSQL?

At FOSDEM someone asked how long 64 bit Transaction-IDs will last.

To refresh: PostgreSQL is currently using 32 bits for the TXID, and is good for around 4 billion transactions:

Pitfalls of missing transactions when handling multiple inserts in MySQL

Imagine, you have a table and a colum is defined NOT NULL. You (and I) expect, that NULL arguments will not go into the table, but instead get rejected.

Good article about comparisation of PostgreSQL and MySQL has a fair comparisation about the two databases engines, not looking at the speed but at more important points like features, ACID, transactions or commercial and 24/7/365 support. In other words, all the things you want, if you decide to use a database in a production environment.

Wie gut repariert man eine Datenbank in MySQL

Letztens in einem IRC Channel:

Atomisch oder doch lieber atomar?

Diese wannabe Datenbank macht immer alles anders:

Google Suche nach “mysql” + “atomisch”

PHP does not need Transactions

Just stumbled about a curiosity: there are 82 functions in the current PostgreSQL part of PHP. Functions like pg_select(), which takes from you the burden of writing a SELECT ... FROM tablename or pg_delete(), pg_insert() and pg_update() which all does, what do you expect: SELECT, DELETE, INSERT or UPDATE, and do the error checking. There are even 7 different functions for getting your results back into PHP.

But there is no function for starting, committing or rolling back a transaction. It seems, the message about the usefulness of transaction has yet not reached the PHP developers. Not that I’m surprised, the standard PHP/MySQL user seems to have no need for transactions …