Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w3A0z-000xlY-1i for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Mar 2026 09:50:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w3A0y-00HUqR-1H for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Mar 2026 09:50:04 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w3A0y-00HUqJ-0N for pgsql-hackers@lists.postgresql.org; Thu, 19 Mar 2026 09:50:04 +0000 Received: from mail-yx1-xb12d.google.com ([2607:f8b0:4864:20::b12d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w3A0u-00000000XHw-3QTg for pgsql-hackers@postgresql.org; Thu, 19 Mar 2026 09:50:03 +0000 Received: by mail-yx1-xb12d.google.com with SMTP id 956f58d0204a3-64ca6595c8aso797223d50.0 for ; Thu, 19 Mar 2026 02:50:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773913801; cv=none; d=google.com; s=arc-20240605; b=ddlKEJa5bUnIQVisYOfKWVBy+/478+ekZaCuP0SrLkcRm/gg35+jKHcH/Z4w5LRKcu F5d6yL3efIJWYPIla4eUUzv2YxmQzYTIPNYHegEgHc9E7msrmS+x6UREioT3CQq46Kin TT0kBBoRPG9fkdU1QSO84CPNU/CkJOrqrgH6mVY02FSyYrEZyHcOXLcZuvUlbtNFG8o6 0+qEKgPADSUPi9AOpPN/CDxgMg9XGuVu+PhAh5Om3caXCsgkkuxzKGv9m+ZN/nSsxDXy rdNIe3EDrWdbZ+684KrWhrb2goKMOWUQlYJd+tzaxu0UipBaH5j1zaup5Fpzww2Nc/zX aqxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Uvj3Ncb8iupCyW8D+iZC6Ar9ERAiLedA5NdQqroenUQ=; fh=+X3g8iRp9Z3ICJ5rpFmGQZvrDldieOSFRt/joAhSJws=; b=JuNxy4GqJGEgD/M4isyQMLHiU0Kcw0fO5SW25bJVGEUOrxlLrdcacAyf63YpVCcZRA CJ1vzr+TZw4UsMF9iNXc1O8hNAknsSa4jinVu1Q8oePMcg3FRPFtcK48VNVVKHdNjLx6 wyGS6PYlLgCHwQpjzID8myfsHzeP44NlDGpnEy5H9M0Pazgrm1Zm7dVOnTCRIrt0npco ugG0FaJ95asEJ+PoR0PKK8hbYMiwZoPbKrHFufVMeSMvjNqrg6UmNpK3KbT0QIaEAp7D A9OVrRzKsdfwbW9+gZDHWDDhQkgXxjjugTNIQELoPLGsVZwVRaI3wcd4JrMZhXXq1q4k TnxA==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773913801; x=1774518601; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Uvj3Ncb8iupCyW8D+iZC6Ar9ERAiLedA5NdQqroenUQ=; b=UCViM4ps+zLXDJhn7SD3kiWWua/6j1Gb8fmn0NJHi3lpGRQngdxZ3Uj1aoGz55OfqP aTy08fc56J3P7ZkTPxhJSI5GE62E/Stym0uKzycCSwhrMtlzmM4rZWuwbLI18xp1vUqk oiIN616eHrBr63UqNtJTMlDslvDQVZ0wr6fFMrFeJJJlNRZ1HARQV8CeI2nqM8pkKtlC QKyqvpvyb1gg/fCuzgZ9fUu1gZ4Msy6WejCkpSMc/zEubyYq1zU/6c86OMHXN51xwd8o t5Sv+mzKn5h5tE2oES/XPPzF2ar9Fyxa2gu3gYbf51y6pvt+xAHEkhhe3aJuL1i/sn3o AMYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773913801; x=1774518601; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Uvj3Ncb8iupCyW8D+iZC6Ar9ERAiLedA5NdQqroenUQ=; b=Ikvo7rI2RAiHLDqpmLYQld8hnQnf0A4KgucZBYAJ/yoGy0p8pe2WBgOzQ5O7WcBWni tn+yUW+B5wzGChuX5zahUoSHLx1PWxgJlqIgFIJY8VEevieiLYnjk71Qn2AUKspr5SQ8 kGgUMfuvcXTFeqw0C/+03POdEUMzase7l5GPpDOo0/bmo9+6O4W81ReNAU96Bw4V7cgc DJmeLvakg8ZYEaTwH4CsXR7Qwery0A+j57mbuj8k8Bs0VGcN8ZS6aAIUVOsJzQPVVi0D 8MBTJimr03K5H6X/n64k3YIKt0TuGBWm5pjq47ORBVTK7St6wjECT816/Siv7NGExsum 9VRA== X-Forwarded-Encrypted: i=1; AJvYcCVi/ubsAsQSr0lKEH+caW/nLIqzLRa/sAFPHy3xJC4RbefpeY1ytoMc5TPfy6qdpVfrs7sZN82vQEl7ABQs@postgresql.org X-Gm-Message-State: AOJu0Yy3op1TBdso7LscOnSVKwDgpPWwcDaRs6s18uFE6jTchiuEQqsD ivZe9a4GwpXjxJQIawtu7Ps3PwIhacm7PrN4hLFFra451JDf9AxqfXdPgSKCrPG51gZWlfAQQdW lz9ZCy5A1wOPzfnS2MLB1jtk66xrAFSQ= X-Gm-Gg: ATEYQzy5/N0O/Z1qmjIwzX/bljvNfEQmkxJvGjvoKqKEe+R8gd18N9m5+sBuP9ZErIS IFKgMGUbWrR3ojGaAD24SU0Jn9z2GhyQN7uQT3+MCv9hsRrjPP458N/L7uGc+NnH4tjsAo4Yuab j9PnNK57r+mKQcqvwVf8SD16loFXuzUx9SICb+7oLELh2c6yB6EIklueaUa+1ptWfAOk4V8ZyHF JU67ncv4UUkXyD7K5aCVz/X7H99LA8ozwq476AZhm3s4Y0TcpTJlZuJVABvy9MqLwGrwfP8pksM BAF+2/Y1SwZCzU2XHBVDAdXAjsigZCfAPcbPCiSJ4Tmsw6RyVeGCrrd9IhqLkZopfz9M4anoCzK SCNc1QWb6N79NZy6D149yVDkQVRi7mijzj/NalIRxk3Of3UVH4O2vZejsVg== X-Received: by 2002:a53:a60a:0:b0:64a:f188:976f with SMTP id 956f58d0204a3-64e9159fa39mr5120020d50.45.1773913801056; Thu, 19 Mar 2026 02:50:01 -0700 (PDT) MIME-Version: 1.0 References: <64f1c69a-ceff-4b17-8298-58f255d075fc@gmail.com> <7f6e0ff9-05e9-4664-9c71-d9dd744362b9@gmail.com> <42ca6abe-774b-404b-b4a2-27d8792b23fb@gmail.com> In-Reply-To: <42ca6abe-774b-404b-b4a2-27d8792b23fb@gmail.com> From: Pavel Stehule Date: Thu, 19 Mar 2026 10:49:24 +0100 X-Gm-Features: AaiRm51EeuFXnTFaFMWtWzJ4Uc6s4TCjWZbDoDrsiwZm4inTYNdEJdmQ5tNV_-Q Message-ID: Subject: Re: Read-only connection mode for AI workflows. To: Andrei Lepikhov Cc: Jack Bonatakis , pgsql-hackers , Bruce Momjian , Andres Freund Content-Type: multipart/alternative; boundary="000000000000f96880064d5d7dcf" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f96880064d5d7dcf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi =C4=8Dt 19. 3. 2026 v 9:40 odes=C3=ADlatel Andrei Lepikhov napsal: > On 19/3/26 08:53, Pavel Stehule wrote: > > We could improve it by restricting manual calls to specific utility > > operations, such as VACUUM or REINDEX. However, we would need some > > specifications first. > > > > > > It doesn't cover possibility to set GUC by set_config function > > Can you explain it? I added a test for the set_config() call. > This extension is so tiny because it exploits the rule: no ro -> rw > switch after a snapshot has been taken (but rw -> ro is possible). The > set_config can=E2=80=99t overcome this rule. > I am sorry. I missed so you used standard_ExecutorStart Regards Pavel > > -- > regards, Andrei Lepikhov, > pgEdge > --000000000000f96880064d5d7dcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

=C4=8Dt 19. 3. 2026 v=C2=A09:= 40 odes=C3=ADlatel Andrei Lepikhov <lepihov@gmail.com> napsal:
On 19/3/26 08:53, Pavel Stehule wrote:
>=C2=A0 =C2=A0 =C2=A0We could improve it by restricting manual calls to = specific utility
>=C2=A0 =C2=A0 =C2=A0operations, such as VACUUM or REINDEX. However, we = would need some
>=C2=A0 =C2=A0 =C2=A0specifications first.
>
>
> It doesn't=C2=A0cover=C2=A0 possibility to set GUC by set_config f= unction

Can you explain it? I added a test for the set_config() call.
This extension is so tiny because it exploits the rule: no ro -> rw
switch after a snapshot has been taken (but rw -> ro is possible). The <= br> set_config can=E2=80=99t overcome this rule.

I am sorry. I missed so you used=C2=A0standard_ExecutorStart

Regards

Pavel
=C2=A0

--
regards, Andrei Lepikhov,
pgEdge
--000000000000f96880064d5d7dcf--