Skip site navigation (1) Skip section navigation (2)

AW: AW: Plans for solving the VACUUM problem

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Mikheev, Vadim'" <vmikheev(at)SECTORBASE(dot)COM>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: AW: AW: Plans for solving the VACUUM problem
Date: 2001-05-23 08:45:17
Message-ID: 11C1E6749A55D411A9670001FA6879633682EF@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> > The downside would only be, that long running txn's cannot
> > [easily] rollback to savepoint.
> 
> We should implement savepoints for all or none transactions, no?

We should not limit transaction size to online available disk space for WAL. 
Imho that is much more important. With guaranteed undo we would need 
diskspace for more than 2x new data size (+ at least space for 1x all modified 
pages unless physical log is separated from WAL).

Imho a good design should involve only little more than 1x new data size.

> 
> > > 2. Abort long running transactions.
> > 
> > This is imho "the" big downside of UNDO, and should not
> > simply be put on the TODO without thorow research. I think it
> > would be better to forget UNDO for long running transactions
> > before aborting them.
> 
> Abort could be configurable.

The point is, that you need to abort before WAL runs out of disk space
regardless of configuration.

Andreas

pgsql-hackers by date

Next:From: Philip WarnerDate: 2001-05-23 08:58:58
Subject: RE: Plans for solving the VACUUM problem
Previous:From: Zeugswetter Andreas SBDate: 2001-05-23 08:26:26
Subject: AW: Plans for solving the VACUUM problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group