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

From Alexander Korotkov
Subject Re: Statement-level rollback
Date
Msg-id CAPpHfdsPQhBmo_BCHg5se0c+YAZiKymO=waMwO-z-gCLVBFdGQ@mail.gmail.com
Whole thread Raw
In response to Re: Statement-level rollback  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Statement-level rollback  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Dec 7, 2018 at 11:34 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> 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.

I'd like to add my 2 cents.

I think usage of subtransaction per statement for statement level
rollback is fair.  It's unlikely we're going to invent something
better in this part.

The issue here is that our subtransaction mechanism is not effective
enough to use it for every statement.  Especially when there are many
statements and each of them touches the only row.  But we can improve
that.

The first thing, which comes to the mind is undo log.  When you have
undo log, then on new subtransaction you basically memorize the
current undo log position.  If subtransaction rollbacks, you have to
just play back undo log until reach memorized position.  This might be
an option for zheap.  But actually, I didn't inspect zheap code to
understand how far we're from this.

But nevetheless, we also have to do something with our heap, which is
not undo-based storage.  I think it is possible to implement a
compromise solution, which allows to accelerate small subtransactions
on heap.  Instead of allocating xid for subtransaction immediately on
write, we can start with using top transaction xid.  But also allocate
small memory buffer to memorize locations of heap tuples added or
modified by this subtransaction.  If we wouldn't overflow this small
buffer, we can use it to rollback state of heap on subtransaction
abort.  Otherwise, we can decide to nevertheless allocate xid for this
subtransaction.  But then xid allocation would happen only for
large-enough subtransactions.  If there is an interest in this, I can
write a POC.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pg_dump emits ALTER TABLE ONLY partitioned_table
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Bug when dumping "empty" operator classes