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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2001-05-23 08:58:58 RE: Plans for solving the VACUUM problem
Previous Message Zeugswetter Andreas SB 2001-05-23 08:26:26 AW: Plans for solving the VACUUM problem