-- テスト用テーブルの準備
CREATE TABLE accounts (
    account_id VARCHAR(10) PRIMARY KEY,
    owner_name VARCHAR(100) NOT NULL,
    balance    DECIMAL(12, 2) NOT NULL DEFAULT 0
                CHECK (balance >= 0)
);
 
INSERT INTO accounts VALUES ('A001', '田中太郎', 100000);
INSERT INTO accounts VALUES ('B002', '鈴木花子', 50000);
 
-- 銀行送金: Atomicityの典型例
BEGIN;
 
-- 送金元の残高を減らす
UPDATE accounts SET balance = balance - 10000
WHERE account_id = 'A001';
 
-- 送金先の残高を増やす
UPDATE accounts SET balance = balance + 10000
WHERE account_id = 'B002';
 
-- 送金元の残高が0未満でないか確認
DO $$
BEGIN
    IF (SELECT balance FROM accounts WHERE account_id = 'A001') < 0 THEN
        RAISE EXCEPTION '残高不足';
    END IF;
END $$;
 
-- 全て成功したらコミット
COMMIT;
 
-- 確認: 合計残高は変わらない（一貫性）
SELECT SUM(balance) FROM accounts;
-- 結果: 150000（送金前と同じ）

-- SAVEPOINTを使った段階的なトランザクション制御
BEGIN;
 
-- 注文の作成（必須処理）
INSERT INTO orders (id, customer_id, total)
VALUES (100, 1, 5000);
SAVEPOINT order_created;
 
-- 注文明細の追加（必須処理）
INSERT INTO order_items (order_id, product_id, quantity, unit_price)
VALUES (100, 1, 2, 2500);
SAVEPOINT items_added;
 
-- ポイント付与（オプション処理 — 失敗しても注文は成立させたい）
DO $$
BEGIN
    INSERT INTO points (customer_id, amount, reason)
    VALUES (1, 50, '注文ポイント');
EXCEPTION WHEN OTHERS THEN
    -- ポイントテーブルが存在しない等のエラーをキャッチ
    RAISE NOTICE 'ポイント付与失敗: %', SQLERRM;
    ROLLBACK TO SAVEPOINT items_added;
    -- ポイント付与のみ取り消し、注文は維持
END $$;
 
-- 在庫の減算（必須処理）
UPDATE products SET stock = stock - 2 WHERE id = 1;
 
COMMIT;
 
-- SAVEPOINTの階層構造:
-- BEGIN
--   └── SAVEPOINT order_created
--         └── SAVEPOINT items_added
--               └── ポイント付与（失敗時はここまでロールバック）
--         └── 在庫減算
-- COMMIT

-- トランザクション単位で設定
BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- ... 操作 ...
COMMIT;
 
-- セッション単位で設定
SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL REPEATABLE READ;
 
-- 現在の分離レベルを確認（PostgreSQL）
SHOW transaction_isolation;
-- 結果: "read committed"（デフォルト）
 
-- MySQL でのデフォルト分離レベル確認
-- SELECT @@transaction_isolation;
-- 結果: "REPEATABLE-READ"（MySQLのデフォルト）
 
-- サーバ全体のデフォルトを変更（postgresql.conf）
-- default_transaction_isolation = 'read committed'

-- ===== READ UNCOMMITTED =====
-- PostgreSQLでは実質READ COMMITTEDとして動作する
-- MySQL InnoDB では実際にダーティリードが発生する
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
 
-- ===== READ COMMITTED（PostgreSQLのデフォルト）=====
-- 各SQL文の開始時にスナップショットを取得
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
SELECT balance FROM accounts WHERE id = 1;  -- 1000
 
-- 他のトランザクションがここでUPDATE→COMMITした場合
SELECT balance FROM accounts WHERE id = 1;  -- 1200（変わる）
-- → 同じトランザクション内でも、最新のCOMMIT済みデータが見える
COMMIT;
 
-- ===== REPEATABLE READ =====
-- トランザクション開始時（最初のクエリ実行時）にスナップショットを取得
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT balance FROM accounts WHERE id = 1;  -- 1000
 
-- 他のトランザクションがここでUPDATE→COMMITしても
SELECT balance FROM accounts WHERE id = 1;  -- 1000（変わらない）
-- → トランザクション開始時のスナップショットを一貫して見続ける
 
-- ただし、自身のUPDATEが他のTxと競合するとエラー
UPDATE accounts SET balance = balance + 100 WHERE id = 1;
-- ERROR: could not serialize access due to concurrent update
COMMIT;
 
-- ===== SERIALIZABLE（最も厳格）=====
-- 直列実行と同等の結果を保証
-- SSI (Serializable Snapshot Isolation) で実装
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
-- 同じデータに対して読み書きが競合するトランザクションがある場合、
-- どちらかがシリアライゼーション失敗エラーで中断される
SELECT SUM(balance) FROM accounts;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;
-- ERROR: could not serialize access due to read/write dependencies
-- → リトライが必要

-- アプリケーション側でのリトライロジック（疑似コード → PL/pgSQL実装）
CREATE OR REPLACE FUNCTION transfer_with_retry(
    p_from_account VARCHAR,
    p_to_account   VARCHAR,
    p_amount       DECIMAL,
    p_max_retries  INTEGER DEFAULT 3
) RETURNS VOID AS $$
DECLARE
    v_retries INTEGER := 0;
    v_success BOOLEAN := FALSE;
BEGIN
    WHILE NOT v_success AND v_retries < p_max_retries LOOP
        BEGIN
            -- SERIALIZABLE分離レベルで実行
            SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
 
            -- 残高確認
            IF (SELECT balance FROM accounts WHERE account_id = p_from_account) < p_amount THEN
                RAISE EXCEPTION '残高不足';
            END IF;
 
            -- 送金実行
            UPDATE accounts SET balance = balance - p_amount
            WHERE account_id = p_from_account;
            UPDATE accounts SET balance = balance + p_amount
            WHERE account_id = p_to_account;
 
            -- 送金履歴記録
            INSERT INTO transfer_log (from_account, to_account, amount, transferred_at)
            VALUES (p_from_account, p_to_account, p_amount, NOW());
 
            v_success := TRUE;
 
        EXCEPTION
            WHEN serialization_failure OR deadlock_detected THEN
                v_retries := v_retries + 1;
                RAISE NOTICE 'リトライ %/% (理由: %)', v_retries, p_max_retries, SQLERRM;
                -- 指数バックオフ的な待機
                PERFORM pg_sleep(0.1 * power(2, v_retries - 1));
        END;
    END LOOP;
 
    IF NOT v_success THEN
        RAISE EXCEPTION '最大リトライ回数超過 (%回)', p_max_retries;
    END IF;
END;
$$ LANGUAGE plpgsql;
 
-- 使用例
SELECT transfer_with_retry('A001', 'B002', 10000);

-- ===== デッドロックの典型的なシナリオ =====
-- ターミナル1 (Tx1):
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE account_id = 'A001';  -- A001をロック
-- ここでTx2がB002をロック
UPDATE accounts SET balance = balance + 100 WHERE account_id = 'B002';  -- B002を待機...
 
-- ターミナル2 (Tx2):
BEGIN;
UPDATE accounts SET balance = balance - 200 WHERE account_id = 'B002';  -- B002をロック
-- Tx1がA001をロック済み
UPDATE accounts SET balance = balance + 200 WHERE account_id = 'A001';  -- A001を待機...
-- → デッドロック発生！
 
-- ===== 対策1: 常に同じ順序でロックする =====
-- すべてのトランザクションがID順にロックを取得すれば循環しない
BEGIN;
-- account_idの昇順でロック取得
UPDATE accounts SET balance = balance - 100 WHERE account_id = 'A001';  -- A→Bの順
UPDATE accounts SET balance = balance + 100 WHERE account_id = 'B002';
COMMIT;
 
-- ===== 対策2: SELECT FOR UPDATEで事前にロック取得 =====
BEGIN;
-- ORDER BYでソートしてからロック取得
SELECT * FROM accounts
WHERE account_id IN ('A001', 'B002')
ORDER BY account_id
FOR UPDATE;
-- ↑ この時点でA001, B002の両方をロック済み
-- 他のTxは待機するが、デッドロックにはならない
 
UPDATE accounts SET balance = balance - 100 WHERE account_id = 'A001';
UPDATE accounts SET balance = balance + 100 WHERE account_id = 'B002';
COMMIT;
 
-- ===== 対策3: ロックタイムアウトの設定 =====
SET lock_timeout = '5s';  -- 5秒でロック待ちを諦める
-- ERROR: canceling statement due to lock timeout
 
-- ===== 対策4: デッドロック検出設定の確認 =====
SHOW deadlock_timeout;
-- デフォルト: 1s（この時間待ってからデッドロック検出を実行）

-- ===== 悲観的ロック（Pessimistic Locking）=====
-- 先にロックを取得してからデータを操作する
-- 適する場面: 競合が頻繁に発生する場合
 
-- 基本形: FOR UPDATE
BEGIN;
SELECT * FROM products WHERE id = 42 FOR UPDATE;
-- → 他のTxのFOR UPDATEは待機
UPDATE products SET stock = stock - 1 WHERE id = 42;
COMMIT;
 
-- NOWAIT: ロック取得不可なら即エラー
SELECT * FROM products WHERE id = 42 FOR UPDATE NOWAIT;
-- ERROR: could not obtain lock on row in relation "products"
-- → アプリ側で即座にエラーハンドリング可能
 
-- SKIP LOCKED: ロック中の行をスキップ（キュー処理向け）
SELECT id, task_data FROM tasks
WHERE status = 'pending'
ORDER BY created_at
LIMIT 1
FOR UPDATE SKIP LOCKED;
-- → ワーカーが並行して未処理タスクを取得
-- → 同じタスクを複数ワーカーが取得することがない
 
-- FOR SHARE: 読み取りロック（他TxのUPDATEは待機、SELECTは許可）
SELECT * FROM products WHERE id = 42 FOR SHARE;
 
 
-- ===== 楽観的ロック（Optimistic Locking）=====
-- ロックを取得せず、更新時に競合を検出する
-- 適する場面: 競合が稀な場合、Web APIなどのステートレス環境
 
-- Step 1: データ読み取り時にバージョンを記録
SELECT id, name, stock, version FROM products WHERE id = 42;
-- → stock=10, version=5
 
-- Step 2: 更新時にバージョンの一致を確認
UPDATE products
SET stock = stock - 1,
    version = version + 1
WHERE id = 42
  AND version = 5;  -- 読み取り時のバージョンと一致するか確認
-- → 影響行数が0なら競合発生 → アプリ側でリトライ
 
-- バージョンカラムの代わりにupdated_atを使う方式
UPDATE products
SET stock = stock - 1,
    updated_at = NOW()
WHERE id = 42
  AND updated_at = '2024-01-15 10:30:00';
-- → タイムスタンプの精度に注意（マイクロ秒まで比較）

-- ===== アドバイザリロック（Advisory Lock）=====
-- テーブルや行ではなく、任意のアプリケーションレベルのロック
-- テーブルへのロック影響がないため、柔軟な排他制御が可能
 
-- セッションレベルのアドバイザリロック
-- 同じキーで取得を試みる他のセッションはブロックされる
SELECT pg_advisory_lock(12345);  -- ロック取得（ブロッキング）
-- ... 排他的な処理 ...
SELECT pg_advisory_unlock(12345);  -- ロック解放
 
-- 非ブロッキング版: ロック取得を試み、取れなければFALSEを返す
SELECT pg_try_advisory_lock(12345);  -- TRUE / FALSE
 
-- トランザクションレベル: COMMIT/ROLLBACK時に自動解放
BEGIN;
SELECT pg_advisory_xact_lock(12345);
-- ... 処理 ...
COMMIT;  -- 自動的にロック解放
 
-- 2つのキーを使う場合（テーブルID + 行ID の組み合わせなど）
SELECT pg_advisory_lock(hashtext('orders'), 42);
 
-- 実用例: 外部APIの重複呼び出し防止
CREATE OR REPLACE FUNCTION process_payment(p_order_id INTEGER)
RETURNS VOID AS $$
BEGIN
    -- 注文IDでアドバイザリロックを取得
    IF NOT pg_try_advisory_xact_lock(hashtext('payment'), p_order_id) THEN
        RAISE EXCEPTION '同じ注文の決済が処理中です';
    END IF;
 
    -- 決済処理（外部API呼び出しを含む）
    UPDATE orders SET status = 'processing' WHERE id = p_order_id;
    -- ... 外部API呼び出し ...
    UPDATE orders SET status = 'paid' WHERE id = p_order_id;
END;
$$ LANGUAGE plpgsql;

-- xmin, xmax の確認
-- PostgreSQLでは隠しカラムとして参照可能
SELECT xmin, xmax, ctid, * FROM accounts WHERE account_id = 'A001';
-- xmin=100, xmax=0, ctid=(0,1), account_id='A001', balance=100000
 
-- 現在のトランザクションIDの確認
SELECT txid_current();
-- 結果: 200
 
-- トランザクション内でUPDATE
BEGIN;
UPDATE accounts SET balance = 90000 WHERE account_id = 'A001';
 
-- 別セッションから確認（READ COMMITTED）
-- → 旧タプル（balance=100000）が見える（Tx200は未コミット）
 
COMMIT;
 
-- 別セッションから再確認
-- → 新タプル（balance=90000）が見える
 
-- スナップショットの確認
SELECT txid_current_snapshot();
-- 結果: '200:205:200,202'
-- 意味: xmin=200, xmax=205, 実行中のTxID=[200, 202]
-- → TxID 200未満はコミット済み、200と202は実行中、
--   201, 203, 204はコミット済み、205以降は未開始

-- 不要なタプル（dead tuple）の確認
SELECT
    schemaname,
    relname AS table_name,
    n_live_tup,          -- 有効なタプル数
    n_dead_tup,          -- 不要なタプル数
    n_mod_since_analyze, -- 最後のANALYZE以降の変更数
    last_vacuum,         -- 最後のVACUUM実行日時
    last_autovacuum,     -- 最後のauto VACUUM実行日時
    last_analyze         -- 最後のANALYZE実行日時
FROM pg_stat_user_tables
WHERE n_dead_tup > 0
ORDER BY n_dead_tup DESC;
 
-- 手動VACUUM（通常はautovacuumに任せる）
VACUUM (VERBOSE) accounts;
-- INFO: "accounts": found 150 removable, 1000 nonremovable row versions
-- INFO: "accounts": removed 150 row versions
 
-- VACUUM FULL: テーブルを完全に書き直す（排他ロック）
-- → 通常はpg_repackを使用する（オンラインで実行可能）
VACUUM FULL accounts;
 
-- autovacuumのパラメータ確認
SHOW autovacuum_vacuum_threshold;       -- 50（デフォルト）
SHOW autovacuum_vacuum_scale_factor;    -- 0.2（デフォルト）
-- → dead tuples > 50 + 0.2 * n_live_tup で自動実行
 
-- テーブル単位でautovacuumの設定を変更
ALTER TABLE accounts SET (
    autovacuum_vacuum_threshold = 100,
    autovacuum_vacuum_scale_factor = 0.05,
    autovacuum_analyze_threshold = 50,
    autovacuum_analyze_scale_factor = 0.02
);
 
-- テーブル膨張率の確認
SELECT
    relname,
    pg_size_pretty(pg_total_relation_size(relid)) AS total_size,
    pg_size_pretty(pg_relation_size(relid)) AS table_size,
    ROUND(100.0 * n_dead_tup / NULLIF(n_live_tup + n_dead_tup, 0), 1) AS dead_pct
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 10;

-- ===== べき等（Idempotent）設計 =====
-- 同じ操作を複数回実行しても結果が変わらない設計
-- ネットワーク障害でリトライが発生する環境では必須
 
-- NG: べき等でない（重複実行で金額が倍になる）
INSERT INTO payments (order_id, amount) VALUES (42, 10000);
 
-- OK: べき等（重複実行しても1回分のみ）
INSERT INTO payments (order_id, amount)
VALUES (42, 10000)
ON CONFLICT (order_id) DO NOTHING;
 
-- OK: 冪等キーを使ったべき等設計
CREATE TABLE payments (
    id              SERIAL PRIMARY KEY,
    idempotency_key UUID UNIQUE NOT NULL,  -- クライアントが生成する一意キー
    order_id        INTEGER NOT NULL,
    amount          DECIMAL(10, 2) NOT NULL,
    status          VARCHAR(20) DEFAULT 'pending',
    created_at      TIMESTAMPTZ DEFAULT NOW()
);
 
-- 冪等キーで重複を防止
INSERT INTO payments (idempotency_key, order_id, amount)
VALUES ('a1b2c3d4-e5f6-7890-abcd-ef1234567890', 42, 10000)
ON CONFLICT (idempotency_key) DO NOTHING
RETURNING *;
-- → 2回目の実行では挿入されず、RETURNINGも空

-- ===== Sagaパターン（マイクロサービス間のトランザクション）=====
-- 各サービスのローカルトランザクション + 補償トランザクションで一貫性を維持
 
-- サガの状態管理テーブル
CREATE TABLE saga_instances (
    saga_id       UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    saga_type     VARCHAR(50) NOT NULL,
    current_step  INTEGER NOT NULL DEFAULT 0,
    status        VARCHAR(20) NOT NULL DEFAULT 'running'
                  CHECK (status IN ('running', 'completed', 'compensating', 'failed')),
    payload       JSONB NOT NULL,
    created_at    TIMESTAMPTZ DEFAULT NOW(),
    updated_at    TIMESTAMPTZ DEFAULT NOW()
);
 
CREATE TABLE saga_steps (
    saga_id       UUID REFERENCES saga_instances(saga_id),
    step_number   INTEGER NOT NULL,
    step_name     VARCHAR(100) NOT NULL,
    status        VARCHAR(20) NOT NULL DEFAULT 'pending',
    result        JSONB,
    executed_at   TIMESTAMPTZ,
    compensated_at TIMESTAMPTZ,
    PRIMARY KEY (saga_id, step_number)
);
 
-- 注文サガの例:
-- Step 1: 在庫予約      → 補償: 在庫予約取消
-- Step 2: 決済実行      → 補償: 返金処理
-- Step 3: 配送手配      → 補償: 配送キャンセル
-- Step 4: 注文確定
 
-- 各ステップはローカルトランザクションで実行
-- 途中で失敗した場合、完了済みステップの補償トランザクションを逆順に実行

-- NG: トランザクション中にユーザー入力を待つ
BEGIN;
SELECT * FROM products WHERE id = 42 FOR UPDATE;
-- ... ユーザーが画面で考え中（数分間ロック保持）...
UPDATE products SET price = 1000 WHERE id = 42;
COMMIT;
 
-- 問題点:
-- 1. 長時間ロックで他のトランザクションがブロック
-- 2. デッドロックのリスク増大
-- 3. MVCC環境でVACUUMが遅延（長命Txがスナップショットを保持）
-- 4. コネクションプールの枯渇
-- 5. レプリケーション遅延の原因
 
-- OK: トランザクションを短く保つ（楽観的ロック）
-- 読取は通常のSELECT、更新時のみ短いトランザクション
SELECT id, price, version FROM products WHERE id = 42;
-- → price=800, version=5
-- ユーザー操作完了後に短いトランザクションで更新
BEGIN;
UPDATE products SET price = 1000, version = version + 1
WHERE id = 42 AND version = 5;  -- 楽観的ロック
-- 影響行数=0ならリトライ
COMMIT;

-- NG: 全てSERIALIZABLEにする
SET default_transaction_isolation = 'serializable';
 
-- 問題点:
-- 1. シリアライゼーション失敗でリトライが頻発（並行性低下）
-- 2. パフォーマンスが20-50%低下する場合がある
-- 3. 多くの場合READ COMMITTEDで十分
-- 4. リトライロジックを全てのトランザクションに実装する必要がある
 
-- OK: 用途に応じて分離レベルを選択
-- 一般的なCRUD操作: READ COMMITTED（デフォルト）
BEGIN;
UPDATE products SET stock = stock - 1 WHERE id = 42;
COMMIT;
 
-- 残高計算や整合性チェック: REPEATABLE READ
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT SUM(balance) FROM accounts;
-- 途中で他のTxが残高を変更してもスナップショットが一貫
COMMIT;
 
-- 厳密な一貫性が必要な金融処理: SERIALIZABLE
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- ダブルスペンディング防止など
COMMIT;

-- NG: BEGINしたまま放置
BEGIN;
SELECT * FROM large_table;
-- ... 接続を保持したまま放置 ...
-- → VACUUMが不要タプルを回収できない
-- → テーブル膨張が進行する
 
-- 問題の検出
SELECT pid, state, query, xact_start,
       NOW() - xact_start AS duration
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND xact_start < NOW() - INTERVAL '5 minutes';
 
-- 対策: idle_in_transaction_session_timeout の設定
SET idle_in_transaction_session_timeout = '10min';
-- → 10分間アイドルなトランザクションを自動的に切断
 
-- postgresql.conf に設定推奨
-- idle_in_transaction_session_timeout = '10min'

-- テスト用テーブル
CREATE TABLE warehouse_items (
    id    INTEGER PRIMARY KEY,
    name  VARCHAR(100) NOT NULL,
    stock INTEGER NOT NULL CHECK (stock >= 0)
);
 
CREATE TABLE shipments (
    id         SERIAL PRIMARY KEY,
    item_id    INTEGER NOT NULL REFERENCES warehouse_items(id),
    quantity   INTEGER NOT NULL,
    shipped_at TIMESTAMPTZ DEFAULT NOW()
);
 
CREATE TABLE notifications (
    id         SERIAL PRIMARY KEY,
    message    TEXT NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW()
);
 
INSERT INTO warehouse_items VALUES (1, '商品A', 10);

CREATE TABLE products (
    id       SERIAL PRIMARY KEY,
    name     VARCHAR(200) NOT NULL,
    stock    INTEGER NOT NULL CHECK (stock >= 0),
    price    DECIMAL(10, 2) NOT NULL,
    version  INTEGER NOT NULL DEFAULT 1,
    updated_at TIMESTAMPTZ DEFAULT NOW()
);
 
INSERT INTO products VALUES (1, 'ノートPC', 5, 98000, 1, NOW());

-- 準備
CREATE TABLE test_accounts (
    id      INTEGER PRIMARY KEY,
    balance INTEGER NOT NULL,
    type    VARCHAR(20) NOT NULL
);
INSERT INTO test_accounts VALUES (1, 1000, 'checking');
INSERT INTO test_accounts VALUES (2, 2000, 'savings');

# デバッグ用ユーティリティ
import logging
import traceback
from functools import wraps
 
# ロガーの設定
logging.basicConfig(
    level=logging.DEBUG,
    format='%(asctime)s [%(levelname)s] %(name)s: %(message)s'
)
logger = logging.getLogger(__name__)
 
def debug_decorator(func):
    """関数の入出力をログ出力するデコレータ"""
    @wraps(func)
    def wrapper(*args, **kwargs):
        logger.debug(f"呼び出し: {func.__name__}(args={args}, kwargs={kwargs})")
        try:
            result = func(*args, **kwargs)
            logger.debug(f"戻り値: {func.__name__} -> {result}")
            return result
        except Exception as e:
            logger.error(f"例外発生: {func.__name__}: {e}")
            logger.error(traceback.format_exc())
            raise
    return wrapper
 
@debug_decorator
def process_data(items):
    """データ処理（デバッグ対象）"""
    if not items:
        raise ValueError("空のデータ")
    return [item * 2 for item in items]

# 設計判断の記録テンプレート
class ArchitectureDecisionRecord:
    """ADR (Architecture Decision Record) の作成"""
 
    def __init__(self, title: str):
        self.title = title
        self.context = ""
        self.decision = ""
        self.consequences = []
        self.alternatives = []
 
    def set_context(self, context: str):
        """背景と課題の記述"""
        self.context = context
        return self
 
    def set_decision(self, decision: str):
        """決定内容の記述"""
        self.decision = decision
        return self
 
    def add_consequence(self, consequence: str, positive: bool = True):
        """結果の追加"""
        self.consequences.append({
            'description': consequence,
            'type': 'positive' if positive else 'negative'
        })
        return self
 
    def add_alternative(self, name: str, reason_rejected: str):
        """却下した代替案の追加"""
        self.alternatives.append({
            'name': name,
            'reason_rejected': reason_rejected
        })
        return self
 
    def to_markdown(self) -> str:
        """Markdown形式で出力"""
        md = f"# ADR: {self.title}\n\n"
        md += f"## 背景\n{self.context}\n\n"
        md += f"## 決定\n{self.decision}\n\n"
        md += "## 結果\n"
        for c in self.consequences:
            icon = "✅" if c['type'] == 'positive' else "⚠️"
            md += f"- {icon} {c['description']}\n"
        md += "\n## 却下した代替案\n"
        for a in self.alternatives:
            md += f"- **{a['name']}**: {a['reason_rejected']}\n"
        return md

-- WAL関連の主要設定
SHOW wal_level;                 -- replica（デフォルト）
SHOW max_wal_size;              -- 1GB（デフォルト）
SHOW min_wal_size;              -- 80MB（デフォルト）
SHOW checkpoint_timeout;        -- 5min（デフォルト）
SHOW synchronous_commit;        -- on（デフォルト）
 
-- パフォーマンス重視の場合（データ損失リスクあり）
-- synchronous_commit = off
-- → COMMITがWAL書き込みを待たない（最大wal_writer_delay分のデータ損失リスク）
-- → 大量のINSERTバッチ処理で有効