Thread: AW: Plans for solving the VACUUM problem

AW: Plans for solving the VACUUM problem

From
Zeugswetter Andreas SB
Date:
> My point is that we'll need in dynamic cleanup anyway and UNDO is
> what should be implemented for dynamic cleanup of aborted changes.

I do not yet understand why you want to handle aborts different than outdated
tuples. The ratio in a well tuned system should well favor outdated tuples.
If someone ever adds "dirty read" it is also not the case that it is guaranteed, 
that nobody accesses the tuple you currently want to undo. So I really miss to see
the big difference.

Andreas


RE: AW: Plans for solving the VACUUM problem

From
"Mikheev, Vadim"
Date:
> Correct me if I am wrong, but both cases do present a problem
> currently in 7.1.  The WAL log will not remove any WAL files
> for transactions that are still open (even after a checkpoint
> occurs). Thus if you do a bulk insert of gigabyte size you will
> require a gigabyte sized WAL directory. Also if you have a simple
> OLTP transaction that the user started and walked away from for
> his one week vacation, then no WAL log files can be deleted until
> that user returns from his vacation and ends his transaction.

Todo:

1. Compact log files after checkpoint (save records of uncommitted  transactions and remove/archive others).
2. Abort long running transactions.

Vadim