Re: Statement-level rollback - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Statement-level rollback
Date
Msg-id 20181207203439.ult7mbdsr6sshza5@alvherre.pgsql
Whole thread Raw
In response to Re: Statement-level rollback  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Statement-level rollback  (Robert Haas <robertmhaas@gmail.com>)
Re: Statement-level rollback  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers
On 2018-Dec-07, Robert Haas wrote:

> Full disclosure: EDB has a feature like this and has for years, but it
> uses a subtransaction per statement, not a subtransaction per row.

Well, this implementation only uses one subtransaction per statement;
Andres says per-row referring to the case of one INSERT per row, so it's
still one statement.

> It is indeed useful to customers, but it also does cause its share of
> problems.  It is *very* easy to burn through a *lot* of XIDs this way,
> even with a subtransaction per statement.  For example, PL code in
> function A can call PL code in function B which can call PL code in
> function C, and you throw in a loop here and an EXCEPTION block there
> and all kinds of fun ensues.

Yeah, I agree that this downside is real.  I think our only protection
against that is to say "don't do that".  Like any other tool, it has
upsides and downsides; we shouldn't keep it away from users only because
they might misuse it.

I would be interested to know if the EDB implementation does something
in a better way than this one; then we can improve ours.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: rewrite ExecPartitionCheckEmitError
Next
From: Robert Haas
Date:
Subject: Re: Statement-level rollback