Re: Statement-level rollback

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Statement-level rollback
Дата
Msg-id 20181207210931.jm63m4gmq5hgwm75@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Statement-level rollback  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Statement-level rollback  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Hi,

On 2018-12-07 16:02:53 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Well, look at this from this point of view: EnterpriseDB implemented
> > this because of customer demand (presumably).  Fujitsu also implemented
> > this for customers.  The pgjdbc driver implemented this for its users.
> > Now 2ndQuadrant also implemented this, and not out of the goodness of
> > our hearts.  Is there any room to say that there is no customer demand
> > for this feature?
> 
> Yeah, but there is also lots of demand for stability in basic
> transactional semantics.  I refer you again to the AUTOCOMMIT business;
> there were a lot of claims that that wouldn't break too much, and they
> were all wrong.

I think it could partially be addressed by not allowing to set it on the
commandline, server config, etc. So the user would have to set it on a
per-connection basis, potentially via the connection string.

I'm quite concerned how this'll make it much harder to write UDFs that
work correctly. If suddenly the error handling expected doesn't work
anymore - because they an error just skips over a statements - a lot of
things will break in hard to understand ways.

Greetings,

Andres Freund


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Statement-level rollback
Следующее
От: Greg Stark
Дата:
Сообщение: Thinking about EXPLAIN ALTER TABLE