How Postgres Makes Transactions Atomic
Thank you for the article, but I do have one quibble:<p><pre><code>  &gt; We could ensure that any process takes out an exclusive lock
  &gt; on a file before reading or writing it, or we could push all
  &gt; operations through a single flow control point so that they
  &gt; only run one at a time. Not only are these workarounds slow,
  &gt; but they won’t scale up to allow us to make our database fully
  &gt; ACID-compliant
</code></pre>
As much as I like Postgres, I also like SQLite, which uses a simple file lock and yet is utterly acidic (<a href="https:&#x2F;&#x2F;www.sqlite.org&#x2F;transactional.html" rel="nofollow">https:&#x2F;&#x2F;www.sqlite.org&#x2F;transactional.html</a>). From SQLite&#x27;s FAQ:<p><pre><code>  &gt; SQLite allows multiple processes to have the database file
  &gt; open at once, and for multiple processes to read the database
  &gt; at once. When any process wants to write, it must lock the
  &gt; entire database file for the duration of its update. But that
  &gt; normally only takes a few milliseconds. . . .
  &gt;
  &gt; If your application has a need for a lot of concurrency, then
  &gt; you should consider using a client&#x2F;server database. But
  &gt; experience suggests that most applications need much less
  &gt; concurrency than their designers imagine.
</code></pre>
---  <a href="https:&#x2F;&#x2F;www.sqlite.org&#x2F;faq.html#q5" rel="nofollow">https:&#x2F;&#x2F;www.sqlite.org&#x2F;faq.html#q5</a>