Rollback capacity - Mailing list pgsql-general

From Jeff Larsen
Subject Rollback capacity
Date
Msg-id d1f9b6f00711071422o75235202nd55b637edd49d81a@mail.gmail.com
Whole thread Raw
Responses Re: Rollback capacity  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

pgsql-general by date:

Previous
From: Ivan Voras
Date:
Subject: Recovering / undoing transactions?
Next
From: Tom Lane
Date:
Subject: Re: Rollback capacity