Re: Statement-level rollback

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Takayuki Tsunakawa <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Subject: Re: Statement-level rollback
Date: 2018-12-07 19:44:17
Message-ID: 20181207194417.kf2e6dxbatc54lis@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018-Dec-07, Andres Freund wrote:

> Hi,
>
> On 2018-12-07 16:20:06 -0300, Alvaro Herrera wrote:
> > case TBLOCK_BEGIN:
> > + s->rollbackScope = XactRollbackScope;
> > s->blockState = TBLOCK_INPROGRESS;
> > + if (s->rollbackScope == XACT_ROLLBACK_SCOPE_STMT)
> > + {
> > + PushTransaction();
> > + s = CurrentTransactionState; /* changed by push */
> > + s->name = MemoryContextStrdup(TopTransactionContext, "pg internal");
> > + StartSubTransaction();
> > + s->blockState = TBLOCK_SUBINPROGRESS;
> > + }
>
> Isn't this going to be performing ridiculously bad, to the point of
> being not much but a trap for users?

If you bulk-load with INSERT under this behavior, yeah it'll create lots
of subtransactions, with the obvious downsides -- eating lots of xids
for one. I think the answer to that is "don't do that". However, if
you want to do 100k inserts and have the 10 bogus of those fail cleanly
(and not abort the other 99990), that's clearly this patch's intention.

> I can see the feature being useful, but I don't think we should accept a
> feature that'll turn bulkloading with insert into a server shutdown
> scenario.

Hm.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-12-07 19:48:06 Re: Statement-level rollback
Previous Message Andres Freund 2018-12-07 19:32:13 Re: Statement-level rollback