<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>SLRU on dbalog.dev</title>
    <link>https://dbalog.dev/tags/slru/</link>
    <description>Recent content in SLRU on dbalog.dev</description>
    <generator>Hugo</generator>
    <language>ko</language>
    <lastBuildDate>Wed, 12 Aug 2026 11:00:00 +0900</lastBuildDate>
    <atom:link href="https://dbalog.dev/tags/slru/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>subtransaction 64개의 벽: SAVEPOINT가 클러스터 전체를 느리게 만드는 경로</title>
      <link>https://dbalog.dev/posts/postgresql-subtransactions-overflow/</link>
      <pubDate>Wed, 12 Aug 2026 11:00:00 +0900</pubDate>
      <guid>https://dbalog.dev/posts/postgresql-subtransactions-overflow/</guid>
      <description>한 트랜잭션이 subtransaction을 64개 넘게 만들면 그 트랜잭션만 느려지는 게 아니라 클러스터 전체가 느려집니다. PlanetScale이 공개한 실측에서는 7,200 TPS가 160 TPS까지 떨어졌습니다. PGPROC 캐시 64개 한계와 pg_subtrans SLRU 조회 경로, hot standby 신규 접속까지 막히는 이유, 그리고 지금 우리 클러스터에서 확인할 진단 쿼리를 정리합니다.</description>
    </item>
  </channel>
</rss>
