it was silly, quick check out of curiosity what Opus 5 can do – and the first thing I saw was so impressive that it made me spend hours during weekend polishing it
here it is from history, without edits
> you're a veteran Postgres hacker and expert. I want 3D visualization of how Postgres works, for browser -- all its major components, presented as a 3d model, complex, with all parts zoomable, and animated, with controls -- checkpointer, bgwriter, autovacuum, walwriter, backends, walsender, etc etc etc. Imagine we need to build a 3d model of whole city. That's same level. We need this so engineers who are non-DB-experts would easily understand how it works. Design must be cool, modern, super cool, running all in browser, with controls, with camera position flying with arrow keys and mouse, zoomable, etc. Think deep how to implement it, which modern cool tech to use, and use ultracode to implement in a new directory (we'll commit it later). OK to use the most cool and most modern stuff. Think deep choose tools wisely and let's build an awesome in-browser 3d model of Postgres engine
(later I came with lots of materials about internals and behavior and we started to polish / improve)
I frequently have asked Claude to explain different software architecture things that I don’t know because I’m not formally technically trained - like “explain Django as though it’s a city with different parts having different roles”. I’m a visual learner so this helps a lot and gives me ideas for how to have similar visualizing for other stuff at various levels of abstraction.
Fair. I had an attempt to clarify it in README that PgQue is "closer to Kafka topics than to a job queue" -- per-subscription cursor on a shared event log, no ACK-delete, no visibility timeout.
That makes PgQue an event-streaming tool, not an MQ. For SKIP LOCKED systems like PGMQ, PgQue can still be a replacement in certain cases – similarly to how Kafka can be a replacement for RabbitMQ or ActiveMQ in certain cases.
> Category: River, Que, and pg-boss (and Oban, graphile-worker, solid_queue, good_job) are job queue frameworks. PgQue is an event/message queue optimized for high-throughput streaming with fan-out.
Yes, I know about this tool, it's great.
I watched videos about how it was developed, what difficulties there
were in achieving delta backups, and how the developers also spent a ton of
time studying the PostgreSQL source code. And I studied the Wal-G source code myself.
I just never had to use it at work, since I was used to pgBackRest and, a
bit later, to Barman. Wal-G focuses on cloud and universality
(i.e., it's not only used for PG, but has a unified interface for many different storage systems).
Initially, I didn't even have the idea of making a complete, reliable tool.
Over time, I started striving toward exactly that.
When there was an available hypervisor at work, I set up k8s there and
ran my receiver for several dev databases, just to test its operation 24/7,
setting aggressive config parameters (frequent compression, unloading, cleanup,
frequent backups, etc.). At the same time, I was choosing not small
databases, but quite real production ones, with various nightly integrations
for data population (external APIs, Airflow, and all that), blobs/tablespaces.
And of course I read your articles, and watched a lot of videos
but I agree, could be better – thinking