PostgresEDI Feb 2026 Meetup — Two Talks
What a great follow-up for our second PostgresEDI meetup! 🐘
First off, a huge thank you for braving the snow 🌨️ last evening in Edinburgh , and many thanks to the two speakers who made it a great night.
We gathered at the University of Edinburgh's Lister Learning and Teaching Centre for another evening of networking and technical deep dives. Pizza and refreshments were kindly sponsored by pgEdge.
It was great to see familiar faces from our launch event as well as new ones too, from application developers eager to learn more about the ecosystem to seasoned systems/database administrators.
For those who couldn't make it, or for those who want to revisit the technical details, here is a recap of the talks with slides and resources.
The Talks
Follow My Leader — connecting client applications after server cutover or failover
Alastair Turner (Percona)
Alastair Turner breaking down connection handling during failover events.
Alastair kicked off the evening with a critical look at the often-hidden "drama" of a failover. It's one thing to promote a replica successfully, but it's entirely another to ensure your client applications can gracefully reconnect to the right Postgres instance.
He framed the solution through the "Dramatis Personae" of the stack: the Application, Network, and Database teams, walking us through options ranging from client library configurations to network-level solutions like HAProxy, PgBouncer, or VIP managers. Crucially, he showed how to pick the right approach based on your environment and your appetite for complexity. A practical talk that resonates with everyone running Postgres in production.
📊 View the slides: Follow my Leader — connecting client applications after server cutover or failover (PDF)
Transactional Job Queues and the Two Generals' Problem
Sean Hammond (seanh.cc)
Sean Hammond discussing the complexities of the Two Generals' Problem.
After the break, Sean took the stage with a proper "story from the trenches". He told the tale of the worst outage in a decade of running Hypothesis: a RabbitMQ failure that not only brought the service to its knees, but silently caused over 21,000 annotations to be saved to Postgres but never indexed into Elasticsearch.
Users were told their work was saved successfully. It wasn't. Sean then walked us through the futureproofing fix: a transactional job table in Postgres that guarantees eventual consistency, with direct indexing for speed and periodic re-indexing for reliability. Wonderful in that it was all about learning from failure and building resilience into systems.
📝 Read the article: Transactional Job Queues
📊 View the slides: Transactional Job Queues and the Two Generals' Problem (PDF)
It's only our second event but the energy in the room is there. People stick around after the talks to chat, ask follow-up questions, and swap stories. That's exactly what we aim to build: a space for the Postgres community in Edinburgh and the North of the UK to connect, share, and learn.
What's Next?
We are already working on the next event! Our next meetup is on Thursday, March 12th.
Register here: 👇
We need speakers and help! If you have an idea for a talk, a story to share, or just want to get involved in volunteering, please drop me an email at vyruss000 (at) gmail.com.
Make sure you are following us for updates:
- Luma calendar: luma.com/PostgresEDI
- LinkedIn: linkedin.com/company/postgresedi
- Mastodon: @PostgresEDI@fosstodon.org
- Bluesky: @postgresedi.bsky.social
Thanks again to Alastair and Sean for two excellent talks, to the UoE for hosting us, and to everyone who came along. See you at the next one! 🍕
/ blog