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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Prevent writes on large objects in read-only transactions
Дата
Msg-id CA+TgmoZLZjjrfumjzk224kcyL6wmTr+x8t2u0QTP=Y0jjopeYQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Prevent writes on large objects in read-only transactions  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Prevent writes on large objects in read-only transactions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Jun 1, 2022 at 1:29 AM Michael Paquier <michael@paquier.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: funcs.sgml - wrong example
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Multi-Master Logical Replication