Hello PostgreSQL Community, We are evaluating a security architecture for isolated AI-agent jobs using Linux, systemd/cgroup v2, job-specific workers and a private PostgreSQL 17 instance.
A separate, controlled import/export service communicates with an existing managed PostgreSQL database. Our requirement is stricter than ordinary query cancellation: For a uniquely identified job, an independent controller must prevent further admission, account for authentication attempts already in progress, identify all related sessions and in-flight operations, terminate only that job's resources, and establish authoritative completion within 480 seconds. We understand that PostgreSQL does not expose a single primitive providing these guarantees. The critical scenario is a network partition occurring after a remote transaction has been submitted but before its completion has been acknowledged. The partition may persist beyond the deadline. We would appreciate technical feedback on five specific questions: 1. Under this failure model, is it possible to guarantee and independently confirm termination of all job-associated database activity within 480 seconds if remote execution remains outside the controller's authority? 2. Would moving job execution and job-specific database connections entirely into a private PostgreSQL environment establish a sufficiently controllable local termination boundary, assuming the controller has independent OS-level authority? 3. Which PostgreSQL mechanisms, session-identity rules and admission controls are necessary to address concurrent connections, pending authentication and PID reuse? 4. For a separate import/export component communicating with managed PostgreSQL, which guarantees can be established for transactions with unknown commit outcomes? What can be achieved through operation identifiers, idempotency and reconciliation, and what remains fundamentally unprovable during a partition? 5. Are there documented protocols, PostgreSQL internals or formal-methods references that would help establish or disprove the required safety and termination properties? We are not seeking to modify PostgreSQL internals or claim that standard session cancellation solves the problem. We want to determine the precise feasibility limits and necessary assumptions before committing to substantial implementation work. References to official PostgreSQL documentation, relevant source code, published research or previously discussed mailing-list threads would be particularly helpful. Thank you for your time and technical guidance. Best regards, Robert Nabenhauer Nabenhauer Consulting
