C libpq Postgres Dynamic Resource Configuration
Publicada el 2026-07-22
Descripción de la oferta
I’m building a low-level control layer in C, talking to PostgreSQL exclusively through libpq. The goal is to let me steer the database in real time—core by core, megabyte by megabyte, and user by user—without relying on pgAdmin, psql scripts, or any third-party orchestration tool. Functional scope • Core-wise processing: I want to pin heavy jobs to specific CPU cores from the client side, exposing an API call where I pass a core map and the session adjusts `SET max_parallel_workers_per_gather`, `cpu_tuple_cost`, or similar parameters on the fly. • RAM-wise resource allocation: Memory ceilings should be adjustable per connection so I can bump or throttle `work_mem`, `shared_buffers`, or temp file limits dynamically. • User-wise messaging queues: Each authenticated user gets an isolated message queue (implemented with NOTIFY/LISTEN or a lightweight queue table) so that background services can publish progress, and consumers can subscribe without polling. Message ordering and at-least-once delivery matter. The workload is transaction-heavy, so every change—parameter tweak, schema hot-patch, or permission flip—has to remain ACID-safe. Your code must wrap each modification in explicit BEGIN/COMMIT blocks and roll back cleanly on failure. Dynamic configuration required • Parameter tuning — expose setter/getter wrappers for the GUCs mentioned above. • Database schema changes — e.g., creating the per-user queue tables on demand. • User permissions — grant, revoke, or alter roles during runtime, again via libpq calls only. Deliverables 1. Clean, well-commented C source (GCC 11+) that compiles on Linux and links solely against libpq. 2. A header exposing the public API (`init_controller()`, `set_core_affinity()`, `set_ram_limit()`, `create_user_queue()` …). 3. SQL helper files, if any, auto-loaded by the C layer. 4. README with build steps, example usage, and a minimal test harness that demonstrates: • changing `work_mem` for one connection while another keeps its original value • pushing a message to a user queue and reading it back in order • running a schema migration inside an explicit transaction and rolling it back on error. Acceptance criteria • No external admin tools invoked—only libpq calls. • All operations are idempotent and survive concurrent sessions. • Code passes the supplied test harness without warnings under `-Wall -Werror`. If this sounds clear and you can deliver tight C code that bends PostgreSQL to my will in real time, let’s get started.
Skills
Fuente original: freelancer