MIME-Version: 1.0
References: 
 <CADsUR0B9bcJQKYHyUMnWcODGzF5+AdeToawULkkTKfrq32Z-8w@mail.gmail.com>
 <64f1c69a-ceff-4b17-8298-58f255d075fc@gmail.com>
 <dde00623-b8e0-421b-a3f7-b149768894ef@app.fastmail.com>
 <fab6a5f3-df9f-4bd7-b2ac-434a17303547@gmail.com>
 <abh1LGa98D2Bpv-n@momjian.us>
 <cbcefd92-4f43-46ef-8c9f-0c45aa8dca77@gmail.com>
 <ablcmDxJ2sqdnf_L@momjian.us>
 <a17ffd88-10c1-41cf-bf40-ca5e99dcba2f@gmail.com>
 <e6079ccd-64c0-492a-8f6f-8c8912fca278@eisentraut.org>
 <wf3p4636lgu67rwatc7pdnvmz36guljm3lzatvvy45ew3adtvw@ip7yivjxqqy6>
 <485a95a4-3220-4165-8be2-9508afd6a0b1@gmail.com>
In-Reply-To: <485a95a4-3220-4165-8be2-9508afd6a0b1@gmail.com>
From: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Date: Thu, 19 Mar 2026 12:39:18 -0700
Message-ID: 
 <CAHg+QDfVrkwmYnGPi9uPJMtcvMhFLhyeDPRx-nLNckKg5UtanQ@mail.gmail.com>
Subject: Re: Read-only connection mode for AI workflows.
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
 Peter Eisentraut <peter@eisentraut.org>,
	Bruce Momjian <bruce@momjian.us>, Jack Bonatakis <jack@bonatak.is>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000fc18db064d65b9ed"
Archived-At: 
 <https://www.postgresql.org/message-id/CAHg%2BQDfVrkwmYnGPi9uPJMtcvMhFLhyeDPRx-nLNckKg5UtanQ%40mail.gmail.com>
Precedence: bulk

--000000000000fc18db064d65b9ed
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Mar 18, 2026 at 7:36=E2=80=AFAM Andrei Lepikhov <lepihov@gmail.com>=
 wrote:

> On 18/3/26 15:26, Andres Freund wrote:
> > Regardless of the AI angle it's quite useful to be able to put a server
> into
> > read only mode, e.g. in preparation for a planned failover where you ca=
n
> > continue to allow reads but don't want any more writes. Or in
> preparation for
> > a shutdown you want to prevent further writes (so the shutdown
> checkpoint is
> > quick), but you do want to allow further reads (to reduce the scope of
> the
> > downtime, by allowing reads while doing a CHECKPOINT before the actual
> > shutdown).
>
> It returns us to the question about cluster-wide V/S session-wide
> read-only mode. Should we design one of them or consider both? What do
> you think?
>

+1 to scenarios Andres' mentioned. Additional cases where a cluster=E2=80=
=91wide
setting is helpful include disk=E2=80=91full events and policy enforcement,=
 where
write access is revoked but read access is preserved for data exfiltration.
Session level is helpful for the AI use cases or to provide controlled user
access. I see value in supporting both.

 Thanks,
Satya

--000000000000fc18db064d65b9ed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><br><div class=3D"gmail_quote gm=
ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 18, =
2026 at 7:36=E2=80=AFAM Andrei Lepikhov &lt;<a href=3D"mailto:lepihov@gmail=
.com">lepihov@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">On 18/3/26 15:26, Andres Freund wrote:<br>
&gt; Regardless of the AI angle it&#39;s quite useful to be able to put a s=
erver into<br>
&gt; read only mode, e.g. in preparation for a planned failover where you c=
an<br>
&gt; continue to allow reads but don&#39;t want any more writes. Or in prep=
aration for<br>
&gt; a shutdown you want to prevent further writes (so the shutdown checkpo=
int is<br>
&gt; quick), but you do want to allow further reads (to reduce the scope of=
 the<br>
&gt; downtime, by allowing reads while doing a CHECKPOINT before the actual=
<br>
&gt; shutdown).<br>
<br>
It returns us to the question about cluster-wide V/S session-wide <br>
read-only mode. Should we design one of them or consider both? What do <br>
you think?<br></blockquote><div><br></div><div>+1 to scenarios Andres&#39; =
mentioned. Additional cases where a cluster=E2=80=91wide setting is helpful=
 include disk=E2=80=91full events and policy enforcement, where write acces=
s is revoked but read access is preserved for data exfiltration. Session le=
vel is helpful for the AI use cases or to provide controlled user access. I=
 see value in supporting both.</div><div><br></div><div>=C2=A0Thanks,</div>=
<div>Satya</div></div></div>

--000000000000fc18db064d65b9ed--