Re: Prevent writes on large objects in read-only transactions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Prevent writes on large objects in read-only transactions
Date: 2022-05-31 19:49:09
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, May 28, 2022 at 5:01 AM Michael Paquier <michael(at)paquier(dot)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

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Przemysław Sztoch 2022-05-31 19:54:05 generate_series for timestamptz and time zone problem
Previous Message Dmitry Koval 2022-05-31 19:43:16 Re: Add SPLIT PARTITION/MERGE PARTITIONS commands