How soon is now in PostgreSQL?
The article discusses a challenge encountered while working with PostgreSQL, specifically related to distributed locking. It highlights the importance of ensuring that only one instance of a message processor is active at a time to avoid issues like duplicated side effects. The author shares insights on a bug found during the implementation of a locking mechanism and the debugging process that followed.
- ▪The author faced difficulties with PostgreSQL while implementing distributed locking in a service called Emmett.
- ▪The system uses PostgreSQL advisory locks and a database table to manage processor ownership and status.
- ▪A bug was discovered in the upsert function that affected the takeover decision when a processor instance crashed.
Opening excerpt (first ~120 words) tap to expand
How soon is now in PostgreSQL? 2026-05-25 oskar dudyczPostgreSQL How soon is now? In PostgreSQL, it’s not always as soon as you’d think. I learned that the hard way recently, so you don’t have to. It took me hours and wasn’t easy to reproduce, even though the fix is one line. I found it in a Cybertec post, as I quite often do when I’m staring at something odd in PostgreSQL. I’m supposed to know my way around the database, but I missed it, which is another reason I want to write this down. I was working on distributed locking in Emmett. When you scale a service horizontally, you can easily end up with two instances of the same message processor running at once. That’s bad.
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at Event-driven.
Discussion
0 commentsMore from Event-driven
