On Tue, Mar 17, 2026 at 03:05:08PM +0100, Andrei Lepikhov wrote: > On 17/3/26 14:52, Bruce Momjian wrote: > > On Tue, Mar 17, 2026 at 11:04:25AM +0100, Andrei Lepikhov wrote: > > > On 16/3/26 22:25, Bruce Momjian wrote: > > > > On Mon, Mar 16, 2026 at 10:01:22PM +0100, Andrei Lepikhov wrote: > > > > > > I do think the underlying problem of safely exposing databases to > > > > > > automated agents is becoming increasingly common, so it seems like a > > > > > > useful area to explore. > > > > > > > > I agree the need a read-only sessions is going to get more urgent with > > > > MCP. Why doesn't the community code have a read-only session option > > > > that can't be changed? > > > > > > The pg_readonly project aims to answer this question: if it is easy and > > > cheap to implement as an extension, why do we need to touch the core? > > > > I think it is a fundamental feature the database should have by default. > > > > Why wasn’t read-only mode set up like this from the start? - I haven’t seen > any other DBMSs, aside from SQLite, offer this kind of guarantee.
I have no idea why. I guess there just wasn't much demand, but now there clearly is with MCP. > If we want to move forward, it makes sense to use a session parameter and > add backend code to prevent violations. Agreed. > Postgres architecture looks well-suited for this feature. However, the > request is to block all backend changes, not just the usual XactReadOnly > limitations, but also things like vacuum, etc (temporary tables?). Should we > also consider cluster-wide restrictions? No, I don't think cluster-wide is in demand, but I might be wrong. -- Bruce Momjian <[email protected]> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
