From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
Subject: | Re: Statement-level rollback |
Date: | 2018-12-07 20:34:39 |
Message-ID: | 20181207203439.ult7mbdsr6sshza5@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-12-07 20:40:49 | Re: Statement-level rollback |
Previous Message | Robert Haas | 2018-12-07 20:32:32 | Re: rewrite ExecPartitionCheckEmitError |