Re: PG and undo logging - Mailing list pgsql-general

From Scott Marlowe
Subject Re: PG and undo logging
Date
Msg-id CAOR=d=2nFvt-CZL1R3cXy_NTkwNCRw+DzAJqDyRHgeaRmVtuQw@mail.gmail.com
Whole thread Raw
In response to PG and undo logging  (Ravi Krishna <sravikrishna3@gmail.com>)
Responses Re: PG and undo logging  (Ravi Krishna <sravikrishna3@gmail.com>)
List pgsql-general
On Sat, May 23, 2015 at 2:34 PM, Ravi Krishna <sravikrishna3@gmail.com> wrote:
> Is it true that PG does not log undo information, only redo. If true,
> then how does it bring a database back to consistent state during
> crash recovery. Just curious.

PostgreSQL is NOT oracle. And it doesn't work like oracle. This is normal.

Ever run an insert with 1M rows, and roll it back in postgresql and
compare that to oracle. Time the rollback in both. That should give
you an idea of how differently the two dbs operate.

A rollback in postgres is immediate because it's already "rolled back"
so to speak. NONE of it's in the main data store yet, it's all in the
transaction log waiting.

Oracle spends it's time and effort creating an "undo" log because it
commits every so often, whether or not you've committed your
transaction.

PostgreSQL doesn't. The whole transaction exists in the transaction
log (called xlog dir in pg lingo.)

When you roll back a pg transaction it literally requires almost no
work. Mark the transaction as aborted etc and get on with life.
Transaction logs get cleaned up as usual in the background and we go
on our way.

This means that Oracle uses space for rollback, while postgres uses
space for "roll forward" (aka the transaction logs) so to speak.

--
To understand recursion, one must first understand recursion.


pgsql-general by date:

Previous
From: Daniel Begin
Date:
Subject: Re: FW: Constraint exclusion in partitions
Next
From: Bill Moran
Date:
Subject: Re: FW: Constraint exclusion in partitions