# Find Postgres Bug

Find latent bugs in a local PostgreSQL source tree (REL_xx_STABLE branch or HEAD) the...

- Repository: https://github.com/digoal/blog (8605 stars)
- Category: Testing
- License: GPL-2.0
- Last updated: 2026-11-01
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add digoal/blog --skill find-postgres-bug -g -a claude-code -y`
Codex: `npx skills add digoal/blog --skill find-postgres-bug -g -a codex -y`
Cursor: `npx skills add digoal/blog --skill find-postgres-bug -g -a cursor -y`
Gemini CLI: `npx skills add digoal/blog --skill find-postgres-bug -g -a gemini-cli -y`

## Description

Find latent bugs in a local PostgreSQL source tree (REL_xx_STABLE branch or HEAD) the way a core hacker does: build a heavily-poisoned debug instance (cassert + cache-discard + -O0/-ggdb3 + core dumps), fuzz it (sqlsmith) until the backend crashes, triage the core into a minimal reproducer (MRE), git-bisect the introducing commit, and render a community-style pgsql-bugs markdown report. The instance never auto-shuts-down. Use when the user says "find a bug in postgres", "fuzz postgres", "hunt for a crash", "test a recent commit", "write a repro", "bisect this crash", "把 PG 跑起来找 bug", "fuzz 一下 postgres", "看看这个 commit 会不会出问题", etc. Triggers whenever the user points at a PG source dir and wants to hunt bugs.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Find Postgres Bug

## Overview

Crash-first bug-hunting pipeline for a local PostgreSQL source tree.
The order matters and is the whole point:

```
poison the build  →  fuzz it  →  triage the core  →  minimise to an MRE
                  →  bisect the commit  →  report (do NOT self-patch)
```

The leverage is front-loaded. A poisoned build does ~90% of the work by
turning latent bugs into immediate crashes; the fuzzer then finds inputs
no human would hand-write. Reading commits by eye is a *secondary*,
targeted probe, used to aim the fuzzer, not as the primary search.

**Source layout assumed:** the standard PG tree (`src/backend/`,
`src/include/`, `contrib/`, `src/test/`, …) at `$PG_SRC_DIR`.

**Three hard rules:**
1. The skill **never** auto-stops the instance. Run `scripts/stop_pg.sh`
   explicitly when done.
2. **Never write a patch.** The deliverable is an MRE + backtrace +
   bisect result, posted upstream. A drive-by fix from someone who just
   met the code is worth less than a clean reproducer.
3. **A finding only counts if it crashes at HEAD, with the tree exactly
   as committed.** Never revert a fix (or commit a staged revert) to make
   something crash and call it a bug, that just re-creates an
   already-fixed bug and is worthless. Before investing in any candidate,
   run the pre-flight in Step 0. See
   [references/already_fixed.md](references/already_fixed.md).

---

## Quick start

```bash
export PG_SRC_DIR=/path/to/postgres

# 1. POISON: configure+build+initdb+start with cassert, cache-discard,
#    -O0 -ggdb3, core dumps enabled. The 90% lever.
./scripts/build_and_start_pg.sh

# 2. SEED + FUZZ: load some tables, then let sqlsmith run (overnight is best)
psql -h /tmp -p 55432 -d postgres -f your_schema.sql   # populate the catalog
./scripts/fuzz_sqlsmith.sh 3600 postgres               # 1h; use 28800 overnight

# 3. TRIAGE: a crash leaves a core under $PGDATA
./scripts/triage_core.sh /path/to/$PGDATA/core.NNNN

The rest: https://github.com/digoal/blog/blob/HEAD/skills/find-postgres-bug/SKILL.md