Re: [HACKERS] Statement-level rollback

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Statement-level rollback
Дата
Msg-id CA+TgmoavJybY0C8LXHZNcw4p=Eh48yoZwbjq8HVa10qhuP=gpg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Statement-level rollback  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [HACKERS] Statement-level rollback  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Fri, Jun 15, 2018 at 4:23 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> I've been looking at re-implementing this feature recently, using
> Tsunakawa's proposed UI of a GUC transaction_rollback_scope that can
> take values "transaction" (default, current behavior) and "statement".
> I didn't take other parts of his patch though; see below.
>
> I think the main objectionable point is that of making servers behave in
> a way that could lose data, if applications assume that transactions
> behave in the way they do today.  I propose that we solve this by
> allowing this feature to be enabled only via one of:
>
> * a PGOPTIONS connection-time option
> * ALTER USER SET (transaction_rollback_scope)
>
> but it can be *disabled* normally via SET.  In other words, changing the
> scope from transaction to statement in a running session is forbidden,
> but changing it the other way around is allowed (if app is unsure
> whether env is unsafe, it can set the scope to "transaction" to ensure
> it's safe from that point onwards).  Changing the scope in
> postgresql.conf is forbidden, so a server is never unsafe as a whole.

I'm not sure that really solves the problem, because changing the GUC
in either direction causes the system to behave differently.  I don't
see any particular reason to believe that changing the behavior from A
to B is any more or less likely to break applications than a change
from B to A.

I put this feature, which - in this interest of full disclosure - is
already implemented in Advanced Server and has been for many years,
more or less in the same category as a hypothetical GUC that changes
case-folding from lower case to upper case.  That is, it's really nice
for compatibility, but you can't get around the fact that every bit of
software that is supposed to run on all PostgreSQL instances has to be
tested in all possible modes, because otherwise you might find that it
doesn't work in all of those modes, or doesn't work as expected.  It
is a behavior-changing GUC par excellence.

Some people are going to love that, and some people are going to hate
it, but I don't think adding some funny GUC mode that only allows it
to be changed in one direction actually makes any difference.  Other
people may, of course, disagree.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Remove mention in docs that foreign keys on partitioned tablesare not supported
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: WAL prefetch