<?xml version="1.0" encoding="utf-8"?>
<!-- The articles of blog.html, newest first. Each entry repeats its article's BlogPosting data
     (headline, address, dates, description); tests/unit/test_website_blog_feed.py holds the two
     together, so a new article goes into this file in the same change. -->
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Guardioz blog</title>
  <subtitle>Notes on PostgreSQL, reliability, and why we're building Guardioz.</subtitle>
  <link rel="self" type="application/atom+xml" href="https://guardioz.com/blog/feed.xml"/>
  <link rel="alternate" type="text/html" href="https://guardioz.com/blog.html"/>
  <id>https://guardioz.com/blog.html</id>
  <updated>2026-10-02T00:00:00Z</updated>
  <author>
    <name>Guardioz</name>
    <uri>https://guardioz.com/</uri>
  </author>
  <entry>
    <title>The logging setting that slows down new connections</title>
    <link rel="alternate" type="text/html" href="https://guardioz.com/blog/log-hostname-explained.html"/>
    <id>https://guardioz.com/blog/log-hostname-explained.html</id>
    <published>2026-10-02T00:00:00Z</published>
    <updated>2026-10-02T00:00:00Z</updated>
    <summary>log_hostname does not add the client to PostgreSQL's log - %h does. It adds a DNS lookup to every new connection. We measured what that costs.</summary>
  </entry>
  <entry>
    <title>max_wal_size, explained</title>
    <link rel="alternate" type="text/html" href="https://guardioz.com/blog/max-wal-size-explained.html"/>
    <id>https://guardioz.com/blog/max-wal-size-explained.html</id>
    <published>2026-07-20T00:00:00Z</published>
    <updated>2026-07-20T00:00:00Z</updated>
    <summary>max_wal_size gives PostgreSQL's transaction log a size budget. Too small, and the server writes the same data again and again. How it works and how to tune it.</summary>
  </entry>
  <entry>
    <title>Why we're building Guardioz</title>
    <link rel="alternate" type="text/html" href="https://guardioz.com/blog/why-we-are-building-guardioz.html"/>
    <id>https://guardioz.com/blog/why-we-are-building-guardioz.html</id>
    <published>2026-06-22T00:00:00Z</published>
    <updated>2026-06-22T00:00:00Z</updated>
    <summary>PostgreSQL keeps the business running. When it slows down, someone has to find out why - and it's rarely a dedicated DBA. A short manifesto on the gap between a symptom and a decision.</summary>
  </entry>
</feed>
