debugging

Attach lldb or gdb to PostgreSQL backends for memory analysis.

Updated Jun 1, 2026

Search Tags:#debugging #postgresql #c #gdb #lldb #internals

Ready to run

npx skills add https://github.com/matejformanek/postgres-claude --skill debugging-matejformanek

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: debugging
Source: https://github.com/matejformanek/postgres-claude/tree/main/.claude/skills/debugging
Command: npx skills add https://github.com/matejformanek/postgres-claude --skill debugging-matejformanek

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill resolves the complexity of debugging a multi-process database engine by providing a structured, safe, and repeatable workflow for attaching to backends, inspecting shared memory, and tracing execution paths.

Core Features & Use Cases

Attach Pattern: Automates the process of attaching lldb or gdb to specific PostgreSQL backends without losing the session.
Instrumentation: Provides patterns for using elog/ereport for logging and memory context inspection to identify leaks.
Advanced Diagnostics: Offers guidance on using AddressSanitizer (ASan), core dump analysis, and SQL-level inspection tools like pageinspect and pg_buffercache.

Quick Start

Use the debugging skill to attach a debugger to a specific backend process and set a breakpoint on the executor function to trace query execution.

Frequently Asked Questions about debugging

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I attach gdb or lldb to a PostgreSQL backend process without losing the session?▼

To debug PostgreSQL backend processes, you can use an automated attach pattern that connects gdb or lldb to specific backends while maintaining your active session. This ensures safe, repeatable instrumentation for tracing query execution.

What is the best way to investigate a SIGSEGV crash in PostgreSQL using core dump analysis?▼

Investigating a PostgreSQL SIGSEGV crash requires core dump analysis using gdb or lldb on a debug-enabled build. This approach traces execution paths to the faulting instruction, enabling precise identification of internal failures.

Do I need a special PostgreSQL build to use AddressSanitizer for debugging internals?▼

Yes, using AddressSanitizer (ASan) for PostgreSQL debugging requires a debug-enabled build of the database engine. ASan provides advanced diagnostics by detecting memory errors during backend execution in development environments.

Can I inspect PostgreSQL shared memory state and buffer cache during execution?▼

You can inspect PostgreSQL shared state using SQL-level inspection tools like pageinspect and pg_buffercache. These tools allow you to examine buffer cache contents and page structures while the database is running.

How does debugging PostgreSQL internals differ from standard application debugging?▼

Debugging PostgreSQL internals involves managing a multi-process database engine architecture, requiring precise attachment to specific backends rather than a single process. It necessitates shared memory inspection and memory context analysis techniques.