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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-06-01 14:01:34
Message-ID: CA+TgmoZLZjjrfumjzk224kcyL6wmTr+x8t2u0QTP=Y0jjopeYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 1, 2022 at 1:29 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> Now the LO handling is quite old, and I am not sure if this is worth
> changing as we have seen no actual complains about that with read-only
> transactions, even if I agree on that it is inconsistent. That could
> cause more harm than the consistency benefit is worth :/

The message that started this thread is literally a complaint about
that exact thing.

We seem to do this fairly often on this list, honestly. Someone posts
a message saying "X is broken" and someone agrees and says it's a good
idea to fix it and then a third person responds and says "let's not
change it, no one has ever {noticed that,cared before,complained about
it}". I wonder whether the people who start such threads ever come to
the conclusion that the PostgreSQL community thinks that they are a
nobody and don't count.

As for the rest, I understand that changing the behavior creates an
incompatibility with previous releases, but I don't think we should be
worried about it. We create far larger incompatibilities in nearly
every release. There's probably very few people using large object
functions in read-only transactions compared to the number of people
using exclusive backup mode, or recovery.conf, or some
pg_stat_activity column that we decided to rename, or accessing
pg_xlog by name in some tool/script. I haven't really heard you
arguing vigorously against those changes, and it doesn't make sense to
me to hold this one, which to me seems to be vastly less likely to
break anything, to a higher standard.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2022-06-01 14:03:18 Re: Multi-Master Logical Replication
Previous Message Justin Pryzby 2022-06-01 12:10:58 Re: funcs.sgml - wrong example