TRAKTOR 2 is out!

Check TRAKTOR 2 - less complicated, more stable, cloud ready! Compatible with PostgreSQL 16 and 17.

TRAKTOR revisited

Working on TRAKTOR again. The good news is, it still works with PostgreSQL 17.x and I have completely replaced psycopg2 with pg8000 to remove all native dependencies. The bad news is, if you don't want to run the arbiter as superuser it's a complicated dance of permissions, some of which can only be GRANTed by a superuser, and I have to find a way to automate this as far as possible.

TRAKTOR, protection for tables in a replicaset

Altering or dropping tables which are in logical replication is not a good idea if the changes are not uniform across a TRAKTOR cluster. So, TABLEs in a replicaset are now protected against DROP TABLE and ALTER TABLE by default using PostgreSQL event triggers.

TRAKTOR, a native trigger function for the fearless

TRAKTOR uses a trigger to break replication cycles on PostgreSQL servers < 16.x. By default, the trigger function tf_break_cycle() is implemented in pl/pgSQL. But now, if you are fearless, there is a native replacement written in C available for pedal-to-the-metal performance.

TRAKTOR: Towards the cloud

TRAKTOR now has the capability to analyze the PostgreSQL server logs through file_fdw or log_fdw, without requiring direct access to the server filesystem any more.

This enables it to work with managed PostgreSQL like AWS RDS and Aurora.

File_fdw and log_fdw seem to be lacking from Azure Database for PostgreSQL.

TRAKTOR, true multimaster replication for PostgreSQL

Hi all,

after the retirement of pgchem::tigress, I stumbled over this Blog post, that showed a method to break the vicious replication cycle when using PostgreSQL logical replication in a multimaster cluster, i.e. all nodes are readers and writers.

For PostgreSQL 16.x, this is not necessary anymore, since it introduced origin=NONE, but for pre-16.x,it works quite well.

Yet, setting up a multimaster cluster is tedious and error prone, so I decided to start a new endeavour and make it easier (that was well before the introduction of pgEdge or pgactive).

So without much furter ado, TRAKTOR was released today. With the help of TRAKTOR, you can set-up true multimaster replication clusters on top of vanilla PostgreSQL servers. Notable features are:

1. Does not need anything beyond a standard PostgreSQL server. No fork, no extension.
2. Shared nothing architecture. No single point of failure,
3. Can automatically heal conflicts in case of split brain situations.
4. REST API for control and monitoring.
5. Works with extensions and custom datataypes, PostGIS and rdkit have been tested.

It does NOT help with designing a robust logical multimaster model! No fancy CRDT datatypes, no vector clocks. And it lacks a comprehensive user's guide yet, but there is a tutorial to get you started.

Static code analysis in PostgreSQL like ORACLE has.

Out of the box, PostgreSQL lacks static code analysis at compile time like ORACLE can do.

plpgsql_check provides this capability (and a profiler), but needs to be called manually. So I tried to emulate ORACLE's behavior with an event trigger.

The plpgsql_compile_check extension is experimental. You MUST preload plpgsql and plpgsql_check with shared_preload_libraries='plpgsql,plpgsql_check' in postgresql.conf, otherwise strange things happen!