Rollback capacity

From: "Jeff Larsen" <jlar310(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Rollback capacity
Date: 2007-11-07 22:22:46
Message-ID: d1f9b6f00711071422o75235202nd55b637edd49d81a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Once again, I'm trying to translate my knowledge of Informix to
PostgreSQL. I tried the manual and Google, but could not find anything
relevant.

Informix keeps transaction logs in a dedicated, pre-allocated disk
area that, until very recent versions, could not grow dynamically. It
is the DBA's responsibility to continually backup these transaction
logs so the space may be recycled. As such, Informix is limited in the
size of a transaction that it can roll back, because it eventually has
to re-use existing transaction log space. If it were to overwrite the
log space containing the beginning of the transaction, it could not
rollback from the internal logs. So if you do something crazy, like
delete 4 million rows, there's a good chance Informix will just throw
an error "long transaction aborted" and roll it back when the
transaction reaches a pre-set high water mark.

How does PostgreSQL handle big transactions and potential rollbacks.
Since the WAL is not strictly pre-allocated space, can it just keep
going until the WAL files fill up the free disk space? What would be
the consequences of such an incident (filling up disk space with WAL
files)? Is the WAL even relevant to rollbacks?

I am aware of the statement_timeout parameter which could prevent huge
transactions, but there is no useful correlation between the time a
statement takes and the server's capacity to roll it back.

Thanks,

Jeff

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-11-07 22:47:09 Re: Rollback capacity
Previous Message Rainer Bauer 2007-11-07 20:30:56 Re: Npsql is much faster than ODBC ?