Patrick Donahue

Senior backend engineer. Ruby on Rails, Go, Postgres. I write about the part of a system that only misbehaves under load. Open to contract work.

[Patrick Donahue @reallevelbrook]

Hospice rules ask volunteers for 5% of patient-care hours. The hard part is work families remember.

With Porchlight a volunteer sits with the patient, questions about their life are read aloud, and the family keeps the recordings and a printed keepsake.

https://t.co/cmtfPZ68lR

[Patrick Donahue @reallevelbrook]

PG 18 changed a default: a generated column without STORED is now VIRTUAL, and you can't index a virtual column.

Rails 8.1 follows it: a virtual column in a migration without stored: true emits VIRTUAL on 18. Back a unique index with one and the migration fails.

[Patrick Donahue @reallevelbrook]

@GaneshKompella Same check, one line: git shortlog -sn --since=90.days. Run it per directory too (add -- app/billing) and you find who holds each part, which is usually more than one person and rarely the org chart.

[Patrick Donahue @reallevelbrook]

@Madeactual Keep that STORED. On PG 18 a generated column defaults to VIRTUAL, and CREATE INDEX on it fails: "indexes on virtual generated columns are not supported". Rails 8.1 follows suit: a virtual column in a migration without stored: true now emits VIRTUAL on 18.

[Patrick Donahue @reallevelbrook]

@akashsairaja Good summary. Two updates for anyone on an older mental model: prepared statements work in transaction mode since 1.21 (max_prepared_statements, default 200 from 1.24), and SET LOCAL is fine since it dies with the transaction. Plain SET is the trap.

[Patrick Donahue @reallevelbrook]

@arthurain Another way out: send columns as arrays. INSERT INTO t (a, b) SELECT * FROM unnest($1::int[], $2::text[]) is one parameter per column, so 42 params whether it's 3k rows or 300k. One prepared statement too, instead of a new one per batch size.

[Patrick Donahue @reallevelbrook]

@CodingwithMagic Two cheap outs: cap the count, SELECT count(*) FROM (SELECT 1 FROM t WHERE .. LIMIT 1001) s, and show "1,000+". Or for an unfiltered list read reltuples from pg_class, which autovacuum keeps close enough for a pager. Exact totals rarely earn their cost.

[Patrick Donahue @reallevelbrook]

@ZidaneZ08902030 Nullable alone shouldn't do it. On PG 18 I added a nullable flag and the index-only scan stayed at 0 heap fetches. It flipped to a heap scan after backfilling the column with an UPDATE (pages lose all-visible) and came back after VACUUM. Worth checking for that.

[Patrick Donahue @reallevelbrook]

A partial index WHERE status = 'pending' only helps if the planner can prove the query matches it.

With a prepared statement (status = $1) and a generic plan, it can't. On PG 18: forced generic plan = seq scan + sort, custom plan = index scan.

Keep that literal in the SQL.

[Patrick Donahue @reallevelbrook]

@ershus @goncaloptomas @dhh @gumroad Nice. One gotcha if Go builds the payload by hand: Sidekiq 8 stores created_at and enqueued_at as epoch milliseconds (7.x used float seconds), and a push is SADD queues <name> plus LPUSH queue:<name>. Skip the SADD and the Web UI won't list the queue.

[Patrick Donahue @reallevelbrook]

@Madeactual The same index also serves ILIKE '%term%' (checked on PG 18: bitmap scan on the trigram GIN), so the plain contains-search gets fast too, not only the % operator. And the % cutoff is the 0.3 similarity threshold, which you can tune per session.

[Patrick Donahue @reallevelbrook]

@PsudoMike One trap: send it as a prepared statement with status = $1 and a generic plan can't prove $1 is 'pending', so it skips the partial index. On PG 18 a forced generic plan gave a seq scan + sort, the custom plan an index scan. Keep the literal in the SQL for those.

[Patrick Donahue @reallevelbrook]

@CodingwithMagic If it's one skewed query you don't have to fight the planner globally: set plan_cache_mode = force_custom_plan for that role, function or session (PG 12+) and it re-plans with the real values on every execute.

[Patrick Donahue @reallevelbrook]

@sonuv_dev Part of why it picks the seq scan: random_page_cost still defaults to 4, a spinning-disk number. On SSD or cloud storage most teams set it near 1.1 and the planner stops undervaluing index scans. Try it with SET in one session before changing it globally.

[Patrick Donahue @reallevelbrook]

@eli_labes @northflank Can't speak to Northflank's docs, but you do want a direct URL for both. LISTEN needs a session the pooler won't hand to anyone else, and Rails migrations take pg_try_advisory_lock, a session lock that transaction pooling breaks (or set advisory_locks: false).

[Patrick Donahue @reallevelbrook]

PgBouncer 1.26.1 is out with three CVEs. The urgent one: under SCRAM auth, a client that knows one user's password could log in as any other SCRAM user, admins included.

It also restores ignore_startup_parameters = search_path to the 1.25 behaviour.

https://t.co/XUJZso0X9F

[Patrick Donahue @reallevelbrook]

@icoretech_inc The one to rush is CVE-2026-107350: under SCRAM auth, a client that knows one user's password could log in as any other SCRAM user, admins included. The two DoS bugs need ignore_startup_parameters or a raised max_packet_size.

[Patrick Donahue @reallevelbrook]

@alazycoder2 One exception worth knowing: list queues with no weights and Sidekiq checks them in strict order, so critical always drains first. Add weights and it becomes weighted random, which is what stops the low queues from starving.

[Patrick Donahue @reallevelbrook]

@toeknee_kim If that runner moves to Postgres 18: file_copy_method = clone plus CREATE DATABASE ... STRATEGY FILE_COPY lets the kernel clone the template's files. On a reflink filesystem (XFS, Btrfs) that shares blocks instead of copying them.

[Patrick Donahue @reallevelbrook]

@hnasr Same trap one level down on 18: the default is worker with 3 io_workers, and io_uring is only accepted if the server was built with liburing. SHOW io_method tells you which one you actually got.