Re: Read-only connection mode for AI workflows.

From: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Andrei Lepikhov <lepihov(at)gmail(dot)com>, Jack Bonatakis <jack(at)bonatak(dot)is>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <bruce(dot)momjian(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Read-only connection mode for AI workflows.
Date: 2026-03-20 12:32:24
Message-ID: CAKAnmmKgYqavU6xUPKgeOwOY0P9EycCmm339+PLaL5f4AQ9fNQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 19, 2026 at 6:09 AM Peter Eisentraut <peter(at)eisentraut(dot)org>
wrote:

> Here is a stalled project to implement ALTER SYSTEM READ ONLY:
>
> https://www.postgresql.org/message-id/flat/CAAJ_b97KZzdJsffwRK7w0XU5HnXkcgKgTR69t8cOZztsyXjkQw%40mail.gmail.com

I think the scope of this request is much smaller than that one, so should
be more doable. That one, IIUC, is more of a ALTER SYSTEM
STOP_ALL_ACTIVITY_EVEN_WAL but we are looking for more of a "stop any overt
changes to our data via any non-select command" while still allowing all
sorts of background/maintenance activity to continue on. Basically,
anything that would cause a pg_dump to be different.

I'm a +1 to the cluster-wide change, and a -1 to the per-connection idea
that started this thread, because I still don't see the need for it when we
have an existing roles/permissions system that gets the job done. You want
your untrusted agent to read from your database? Create a specific role for
that. If our existing per-role access controls are not sufficient, improve
them.

Cheers,
Greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mihail Nikalayeu 2026-03-20 12:35:00 Re: Adding REPACK [concurrently]
Previous Message Amit Kapila 2026-03-20 11:56:02 Re: Skipping schema changes in publication