jeeybee

Added a mcp command for it, but i might add it as a comfig as well?

https://github.com/janbjorge/rekal/pull/14/changes

Thanks, i will look into making them configurable.

The 0.4/0.4/0.2 weights are just based of hand wavy trail an error, will look into other options. I could make them configurable?

Thanks! You're right, that's just a relic of my dev environment. Will broaden the version requirement.

Did you test with fillfactor < 100 on the queue table? With HOT updates, status changes can reuse dead space without creating new index entries, which seems like it could significantly delay the onset of the death spiral?

No config step, the tools discover everything from pg_catalog at call time. list_schemas → list_tables → describe_table is the typical agent workflow, and there's a query_guide prompt baked in that suggests that progression.

On query guardrails: every query runs in a readonly transaction and results are capped at 500 rows via a wrapping SELECT * FROM (...) sub LIMIT 500. There's also explain_query which returns the plan without executing, so agents can check before running something expensive. That said, there's no cost-based gate that blocks a bad plan automatically; that's an interesting idea worth exploring.

Thanks! Read-only felt like the obvious constraint; agents shouldn't need write access to understand a database.

Most Postgres MCP servers expose query and list_tables. Agents end up guessing column values, enum casing, and join paths - then retrying until something works.

pglens gives agents the context to get it right the first time: column_values shows real distinct values with counts, find_join_path does BFS over the FK graph and returns join conditions through intermediate tables, describe_table gives columns/PKs/FKs/indexes in one call. Plus production health tools like bloat_stats, blocking_locks, and sequence_health.

Everything runs in readonly transactions, identifiers escaped via Postgres's quote_ident(), no extensions required. Works on any Postgres 12+ (self-hosted, RDS, Aurora, etc.). Two dependencies: asyncpg and mcp.

https://github.com/janbjorge/pglens

pip install pglen

I maintain a small Postgres-native job queue for Python called PGQueuer: https://github.com/janbjorge/pgqueuer

It uses the same core primitives people are discussing here (FOR UPDATE SKIP LOCKED for claiming work; LISTEN/NOTIFY to wake workers), plus priorities, scheduled jobs, retries, heartbeats/visibility timeouts, and SQL-friendly observability. If you’re already on Postgres and want a pragmatic “just use Postgres” queue, it might be a useful reference / drop-in.

If you like the “use Postgres until it breaks” approach, there’s a middle ground between hand-rolling and running Kafka/Redis/Rabbit: PGQueuer.

PGQueuer is a small Python library that turns Postgres into a durable job queue using the same primitives discussed here — `FOR UPDATE SKIP LOCKED` for safe concurrent dequeue and `LISTEN/NOTIFY` to wake workers without tight polling. It’s for background jobs (not a Kafka replacement), and it shines when your app already depends on Postgres.

Nice-to-haves without extra infra: per-entrypoint concurrency limits, retries/backoff, scheduling (cron-like), graceful shutdown, simple CLI install/migrations. If/when you truly outgrow it, you can move to Kafka with a clearer picture of your needs.

Repo: https://github.com/janbjorge/pgqueuer

Disclosure: I maintain PGQueuer.

I’ve always loved Slack. It’s been core to how we work, and I’ve recommended it to countless others.

But seeing how they just treated Hack Club — sudden 40x price hike, almost no notice, threatening to cut off access and delete 11 years of history — makes me wonder if we should rethink where we build our work.

I don’t want to leave Slack. But I also don’t want to wake up one day with our team’s history held hostage.

pgqueuer turns vanilla PostgreSQL into horizontally-scalable job queue with zero extra infrastructure. If you’re running Postgres and want to ditch extra queue clusters, give it a spin and let me know how it holds up.

https://github.com/janbjorge/pgqueuer

I've observed something interesting: my toddler can quickly and somewhat effortlessly solve a simple physical puzzle, yet when I try to prompt large language models (LLMs) to guide me clearly through the solution, they struggle.

Even with clear photographs and detailed instructions, LLMs tend to give general advice or indirect methods rather than precise, actionable steps that clearly demonstrate correctness.

Have you tried something similar? Have you successfully "prompt-engineered" an LLM into giving clear, precise, step-by-step solutions for physical puzzles? If yes, what's your approach?

Kudos to the author for diving in and uncovering the real story here. The Python 3.14 tail-call interpreter is still a nice improvement (any few-percent gain in a language runtime is hard-won), just not a magic 15% free lunch. More importantly, this incident gave us valuable lessons about benchmarking rigor and the importance of testing across environments. It even helped surface a compiler bug that can now be fixed for everyone’s benefit. It’s the kind of deep-dive that makes you double-check the next big performance claim. Perhaps the most thought-provoking question is: how many other “X% faster” results out there are actually due to benchmarking artifacts or unknown regressions? And how can we better guard against these pitfalls in the future?

This post is a perfect reminder of Gandhi’s advice: "Be the change you want to see in the world." We can’t expect kids to trust or wait for better outcomes unless we first model consistency and patience ourselves. Our everyday actions—keeping promises, showing reliability—are the real lessons that shape their future.

Cool, to put on a bit of a tin hat, how do we know that the model is not tuned to infringe on what we in the West would consider censorship or misinformation?

Thanks,

I haven't deployed PipeGate on AWS; it started as a personal curiosity project. There are probably many security aspects that would need to be addressed before deploying it in a production environment.

Thanks for the detailed response—lots of good points here.

IT's main concern is blocking any external traffic from hitting local machines, even if tunneled or encrypted. Outbound traffic is generally fine, but many external platforms require direct URLs for real-time webhooks, which makes solutions like ngrok hard to replace.

Polling an external queue from the LAN is an interesting idea—I’ll check if IT might allow that. Long-lived tunnels like SSH or Cloudflare are probably a no-go given their restrictions.

So far, no comments regarding compliance or privacy.

Thanks again for the input!

Interesting, but sounds very similar to the ngroks ssh-option?

Cool, dropped an email.

Good point about SKIP LOCKED inefficiencies with mixed-duration jobs. In PGQueuers benchmarks, throughput reached up to 18k jobs/sec, showing it can handle high concurrency well. For mixed workloads, strategies like batching or partitioning by job type can help.

While a separate "running" table reduces skips, it adds complexity. SKIP LOCKED strikes a good balance for simplicity and performance in many use cases.

One known issue is that vacuum will become an issue if the load is persistent for longer periods leading to bloat.

I think PGQueuers main advantage is simplicity; no extra infrastructure is needed, as it runs entirely on PostgreSQL. This makes it ideal for projects already using Postgres and operational familiarity. While it may lack the advanced features or scalability of dedicated systems like Kafka or RabbitMQ, it’s a great choice for lightweight without the overhead of additional services.

PGQueuer is a lightweight job queue for Python, built entirely on PostgreSQL. It uses SKIP LOCKED for efficient and safe job processing, with a minimalist design that keeps things simple and performant.

If you’re already using Postgres and want a Python-native way to manage background jobs without adding extra infrastructure, PGQueuer might be worth a look: GitHub - https://github.com/janbjorge/pgqueuer

Thanks! This is exactly why I wrote it. So far, it has been a nice simplification that allows me to "just get on with it."

Im excited to announce the release of PGQueuer v0.15.0!

PGQueuer is a minimalist, high-performance job queue library for Python that leverages PostgreSQL's robustness, designed for real-time, high-throughput background job processing.

Key Features in This Release:

- Recurring Job Scheduling: You can now easily schedule recurring jobs using cron-like expressions with the new SchedulerManager. Ideal for automating routine tasks like data synchronization or cleanups.

PGQueuer provides job queuing, locking, and real-time notifications using PostgreSQL's FOR UPDATE SKIP LOCKED and LISTEN/NOTIFY. It's a minimalist alternative for those already using PostgreSQL, avoiding the need for Redis.

- https://github.com/janbjorge/PGQueuer

disclaimer: Im the auther.

Used Zed for a week or so, loved it! But the lack of mypy / git integrations forced me back to VS-code :'(

Got a pihole a few years ago, works like a charm. The only annoyance is when you actually look for produces and nearly all links in google are dead due to ads.

Unsure whats going on, but unable to add links to my question.

- https://github.com/janbjorge/pgqueuer

- https://news.ycombinator.com/item?id=41284703

Hi everyone!

I’m currently enhancing the documentation for my project, PGQueuer.

About PGQueuer: PGQueuer is a minimalist, high-performance job queue library for Python, leveraging PostgreSQL’s LISTEN/NOTIFY for efficient job management. It’s perfect for handling background tasks and managing workflows with simplicity and reliability

https://github.com/janbjorge/pgqueuer