RE: Plans for solving the VACUUM problem - Mailing list pgsql-hackers

From Mikheev, Vadim
Subject RE: Plans for solving the VACUUM problem
Date
Msg-id 3705826352029646A3E91C53F7189E32016657@sectorbase2.sectorbase.com
Whole thread Raw
In response to Plans for solving the VACUUM problem  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: RE: Plans for solving the VACUUM problem
Next
From: "Mikheev, Vadim"
Date:
Subject: RE: Plans for solving the VACUUM problem