Re: Prevent writes on large objects in read-only transactions - Mailing list pgsql-hackers

From Yugo NAGATA
Subject Re: Prevent writes on large objects in read-only transactions
Date
Msg-id 20220530174418.9a3e508d1d1a5e42f7958da7@sraoss.co.jp
Whole thread Raw
In response to Re: Prevent writes on large objects in read-only transactions  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Prevent writes on large objects in read-only transactions
List pgsql-hackers
On Sat, 28 May 2022 18:00:54 +0900
Michael Paquier <michael@paquier.xyz> wrote:

> On Fri, May 27, 2022 at 03:30:28PM +0900, Yugo NAGATA wrote:
> > Currently, lo_creat(e), lo_import, lo_unlink, lowrite, lo_put,
> > and lo_from_bytea are allowed even in read-only transactions.
> > By using them, pg_largeobject and pg_largeobject_metatable can
> > be modified in read-only transactions and the effect remains
> > after the transaction finished. Is it unacceptable behaviours, 
> > isn't it?
> 
> 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.

Thank you for your comment. I am fine with leaving the behaviour in
read-only transactions as is if anyone don't complain and there are no
risks. 

As to the error messages during recovery, I think it is better to improve
it, because the current messages are emitted by elog() and it seems to imply
they are internal errors that we don't expected. I attached a updated patch
for it.

Regards,
Yugo Nagata

-- 
Yugo NAGATA <nagata@sraoss.co.jp>

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: ParseTzFile doesn't FreeFile on error
Next
From: "wangw.fnst@fujitsu.com"
Date:
Subject: RE: Perform streaming logical transactions by background workers and parallel apply