<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Postgres on Bhaak&#39;s Blog</title>
    <link>https://bhaak.net/blog/tags/postgres/</link>
    <description>Recent content in Postgres on Bhaak&#39;s Blog</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 05 Mar 2026 12:43:14 +0100</lastBuildDate>
    <atom:link href="https://bhaak.net/blog/tags/postgres/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Avoid Integer for File Sizes in Postgres</title>
      <link>https://bhaak.net/blog/posts/2026-03-05-avoid-integer-for-file-sizes-in-postgres/</link>
      <pubDate>Thu, 05 Mar 2026 12:43:14 +0100</pubDate>
      <guid>https://bhaak.net/blog/posts/2026-03-05-avoid-integer-for-file-sizes-in-postgres/</guid>
      <description>&lt;p&gt;Here’s a small bug we recently encountered in production.&#xA;Occasionally, PDF generation jobs would fail, and the cause turned out to be&#xA;a small oversight when designing database tables.&lt;/p&gt;&#xA;&lt;p&gt;The PDF metadata is stored in a table, and the column for file size was defined&#xA;as &lt;code&gt;integer&lt;/code&gt;, also known as &lt;code&gt;int4&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Since this data type is signed in Postgres, those 4 bytes only allow for files&#xA;up to 2.1 GB (2 147 483 647 bytes).&#xA;You might think, 2^31 bytes ought to be enough for everybody &amp;hellip; except&#xA;apparently for our PDFs.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
