Re: Statement-level rollback

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: Statement-level rollback
Дата
Msg-id CAPpHfdsPQhBmo_BCHg5se0c+YAZiKymO=waMwO-z-gCLVBFdGQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Statement-level rollback  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Statement-level rollback  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: pg_dump emits ALTER TABLE ONLY partitioned_table
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] Bug when dumping "empty" operator classes