Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, May 28, 2022 at 5:01 AM Michael Paquier <michael@paquier.xyz> wrote:
>> Well, there is an actual risk to break applications that have worked
>> until now for a behavior that has existed for years with zero
>> complaints on the matter, so I would leave that alone. Saying that, I
>> don't really disagree with improving the error messages a bit if we
>> are in recovery.
> On the other hand, there's a good argument that the existing behavior
> is simply incorrect.
Yeah. Certainly we'd not want to back-patch this change, in case
anyone is relying on the current behavior ... but it's hard to argue
that it's not wrong.
What I'm wondering about is how far the principle of read-only-ness
ought to be expected to go. Should a read-only transaction fail
to execute adminpack's pg_file_write(), for example? Should it
refuse to execute random() on the grounds that that changes the
session's PRNG state? The latter seems obviously silly, but
I'm not very sure about pg_file_write(). Maybe the restriction
should be "no changes to database state that's visible to other
sessions", which would leave outside-the-DB changes out of the
discussion.
regards, tom lane