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

Re: Savepoints

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: Savepoints
Date: 2002-01-24 19:11:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> > How about: use overwriting smgr + put old records into rollback
> > segments - RS - (you have to keep them somewhere till TX's running
> > anyway) + use WAL only as REDO log (RS will be used to rollback TX'
> > changes and WAL will be used for RS/data files recovery).
> > Something like what Oracle does.
> As long as we use no overwriting manager
> 1) Rollback(data) isn't needed in case of a db crash.
> 2) Rollback(data) isn't needed to cancal a transaction entirely.

-1) But vacuum must read a huge amount of data to remove dirt.
-2) But TX-s must read data they are not interested at all.

> 3) We don't need to mind the transaction size so much.

-3) The same with overwriting smgr and WAL used *only as REDO log*:
we are not required to keep WAL files for duration of transaction
- as soon as server knows that changes logged in some WAL file
applied to data files and RS on disk (and archived, for WAL-based
BAR) that file may be reused/removed. Old data will still occupy
space in RS but their space in data files will be available
for reuse.

> We can't use the db any longer if a REDO recovery fails now.

Reset WAL and use/dump it. Annoying? Agreed. Fix bugs and/or
use good RAM - whatever caused problem with restart.

> Under overwriting smgr we can't use the db any longer either
> if rollback fails.

Why should it fail? Bugs? Fix them.

> How could PG be not less reliable than now ?

Is today' RG more reliable than Oracle, Informix, DB2?



pgsql-hackers by date

Next:From: Jan WieckDate: 2002-01-24 19:14:45
Subject: Re: PostgreSQL crashes with Qmail-SQL
Previous:From: Tom LaneDate: 2002-01-24 18:57:34
Subject: Re: 7.1.4

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