RE: Plans for solving the VACUUM problem

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Zeugswetter Andreas SB'" <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'Don Baccus'" <dhogaza(at)pacifier(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: RE: Plans for solving the VACUUM problem
Date: 2001-05-25 17:05:31
Message-ID: 3705826352029646A3E91C53F7189E32016657@sectorbase2.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > > >Oracle has MVCC?
> > >
> > > With restrictions, yes.
> >
> > What restrictions? Rollback segments size?
>
> No, that is not the whole story. The problem with their
> "rollback segment approach" is, that they do not guard against
> overwriting a tuple version in the rollback segment.
> They simply recycle each segment in a wrap around manner.
> Thus there could be an open transaction that still wanted to
> see a tuple version that was already overwritten, leading to the
> feared "snapshot too old" error.
>
> Copying their "rollback segment" approach is imho the last
> thing we want to do.

So, they limit size of rollback segments and we don't limit
how big our datafiles may grow if there is some long running
transaction in serializable mode. We could allow our rollback
segments to grow without limits as well.

> > Non-overwriting smgr can eat all disk space...
> >
> > > You didn't know that? Vadim did ...
> >
> > Didn't I mention a few times that I was inspired by Oracle? -:)
>
> Looking at what they supply in the feature area is imho good.
> Copying their technical architecture is not so good in general.

Copying is not inspiration -:)

Vadim

Browse pgsql-hackers by date

  From Date Subject
Next Message Mikheev, Vadim 2001-05-25 17:52:17 RE: Plans for solving the VACUUM problem
Previous Message Mikheev, Vadim 2001-05-25 16:37:16 RE: Plans for solving the VACUUM problem