Install
$ agentstack add skill-pumarogie-claude-postgres-skills-postgres-advanced-patterns ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Postgres Advanced Patterns
Overview
Postgres supplies the primitives; the application must define ownership, crash recovery, idempotency, retries, and operational bounds.
1. Atomically claim queued work
Claim and mark a batch atomically. SKIP LOCKED lets concurrent workers select disjoint rows:
UPDATE jobs AS j
SET status = 'running',
lease_owner = $1,
lease_expires_at = clock_timestamp() + interval '5 minutes',
attempts = attempts + 1
FROM (
SELECT id
FROM jobs
WHERE status = 'pending'
ORDER BY priority DESC, id
FOR UPDATE SKIP LOCKED
LIMIT $2
) AS claim
WHERE j.id = claim.id
RETURNING j.*;
If selection and update are separate statements, they must share one explicit transaction; otherwise commit releases the row locks before ownership is recorded.
Always use SKIP LOCKED for competing queue workers. Plain FOR UPDATE makes workers wait on rows another worker is claiming instead of moving to available work.
Keep the claim path small with a partial index:
CREATE INDEX CONCURRENTLY idx_jobs_pending_claim
ON jobs (priority DESC, id)
WHERE status = 'pending';
Recover crashes with expiring leases. Workers extend only leases they own; a sweeper returns expired work to pending with an attempt limit and dead-letter policy. Effects must be idempotent because a worker can finish after lease expiry.
UPDATE jobs
SET status = 'pending', lease_owner = NULL, lease_expires_at = NULL
WHERE status = 'running' AND lease_expires_at < clock_timestamp()
RETURNING id;
2. Batch writes
For high-rate bulk ingestion, follow this order:
- Use PostgreSQL
COPY—pgxCopyFromin Go—for bulk load specifically. It is the preferred path when loading many compatible rows; do not stop at a larger multi-rowINSERTor statement batch. - Use bounded multi-row inserts or driver batches when
COPYdoes not fit. Bound batch size to control memory, WAL bursts, and lock duration. - If the group must be atomic, wrap it in an explicit transaction; never assume a driver's batch API is implicitly transactional.
- Close every pgx
BatchResults, check statement errors, and check the final close error. Never fire-and-forget a batch.
Both COPY and batching remove per-row round trips; measure batch size under production-like load.
3. Maintain time-based partitions
Partition unbounded event/log tables by the retention and pruning column. A mass DELETE creates dead tuples and does not return relation space to the filesystem. Dropping or detaching old partitions avoids that dead-tuple and WAL load; partitions vacuum independently.
Partitioning adds planning, indexing, uniqueness, and maintenance costs. Automate creation ahead of writes and retention after safety checks. Use native declarative partitioning with a scheduled job or pg_partman; never rely on manual creation. Monitor how out-of-range rows fail or enter a default partition.
For an existing huge unpartitioned table, do not present partitioning as greenfield DDL. Create the partitioned target, capture concurrent writes, backfill bounded time/key ranges in separate transactions, reconcile, cut over, and retain a rollback window. Use the live-table move workflow below.
4. Move data between live large tables
- Create the target with a uniqueness constraint.
- Capture writes with an idempotent trigger or durable change stream.
- Backfill bounded key ranges in separate transactions.
- Reconcile content, then switch readers and writers.
- Retire capture and source only after a rollback window.
Silent DO NOTHING can hide divergent rows. Follow writing-safe-migrations for live DDL and tuning-autovacuum-and-bloat for backfill impact.
Common Mistakes
- Selecting a job and committing before updating its status.
- Using leases without expiry, heartbeats, idempotency, or a retry ceiling.
- Letting batches grow without bounds.
- Creating time partitions by hand after writes have already reached the boundary.
- Migrating a large table in one transaction or dropping the source before reconciliation.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: pumarogie
- Source: pumarogie/claude-postgres-skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.