| From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
|---|---|
| To: | "'Mikheev, Vadim'" <vmikheev(at)SECTORBASE(dot)COM>, "'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: | AW: Plans for solving the VACUUM problem |
| Date: | 2001-05-25 07:44:14 |
| Message-ID: | 11C1E6749A55D411A9670001FA6879633682F3@sdexcsrv1.f000.d0188.sd.spardat.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > >> Impractical ? Oracle does it.
> > >
> > >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.
> 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.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oleg Bartunov | 2001-05-25 08:38:44 | Re: GiST index on data types that require compression |
| Previous Message | Oliver Elphick | 2001-05-25 06:08:15 | Bug#98643: plpgsql SELECT INTO causes trouble when assignment impossible (fwd) |