parallel-query

Manage ParallelContext lifecycles and shared memory for PostgreSQL parallel queries.

Updated Jun 1, 2026
One-click install
npx skills add https://github.com/matejformanek/postgres-claude --skill parallel-query
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: parallel-query
Source: https://github.com/matejformanek/postgres-claude/tree/main/.claude/skills/parallel-query
Command: npx skills add https://github.com/matejformanek/postgres-claude --skill parallel-query

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill eliminates the risk of hallucinating PostgreSQL parallel-query conventions, such as incorrect locking orders, improper DSM usage, or unsafe function markings, ensuring your backend patches and extensions are robust and performant.

Core Features & Use Cases

  • ParallelContext Lifecycle Management: Provides a procedural cookbook for managing the lifecycle of parallel workers, including DSM allocation and TOC key management.
  • Safety & Compliance: Guides the correct application of PARALLEL SAFE, RESTRICTED, and UNSAFE markings for SQL-callable functions and custom executor nodes.
  • Use Case: When developing a custom PostgreSQL extension that requires parallel execution, use this skill to correctly plumb your code into execParallel.c and ensure your shared memory state is handled without deadlocks or race conditions.

Quick Start

Use the parallel-query skill to guide the implementation of a new parallel-aware executor node and verify the required DSM lifecycle hooks.

Frequently Asked Questions about parallel-query

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

FAQPage Schema
How do I manage the ParallelContext lifecycle when developing PostgreSQL backend extensions?

To implement a parallel-aware PostgreSQL executor node, you must plumb your code into execParallel.c and verify the required DSM lifecycle hooks to manage shared memory state across worker-leader communication.

How does dynamic shared memory handle worker-leader communication in PostgreSQL parallel queries?

PostgreSQL parallel queries use DSM primitives to handle worker-leader communication, relying on internal APIs like shm_toc for shared memory allocation and lock-group membership to coordinate state across parallel workers.

When do I need to mark SQL functions as PARALLEL SAFE, RESTRICTED, or UNSAFE in PostgreSQL?

You must apply PARALLEL SAFE, RESTRICTED, or UNSAFE markings to SQL-callable functions when developing custom PostgreSQL extensions to ensure function safety and prevent unsafe concurrent execution.

What are the common limitations when writing custom parallel-aware executor nodes in PostgreSQL?

Limitations of PostgreSQL parallel-aware executor nodes include the risk of incorrect locking orders, improper DSM usage, and unsafe function markings, which can cause deadlocks and race conditions if internal API conventions are not followed.