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

AW: AW: Re: Backup and Recovery

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: AW: AW: Re: Backup and Recovery
Date: 2001-07-06 14:00:34
Message-ID: 11C1E6749A55D411A9670001FA68796336836A@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> >> Ideally the archiving
> >> process would also discard records from aborted transactions, but I'm
> >> not sure how hard that'd be to do.
> 
> > Unless we have UNDO we also need to roll forward the physical changes of 
> > aborted transactions, or later redo records will "sit on a 
> wrong physical image".
> 
> Wouldn't it be the same as the case where we *do* have UNDO?  How is a
> removed tuple different from a tuple that was never there?

HiHi, the problem is a subtile one. What if a previously aborted txn 
produced a btree page split, that would otherwise not have happened ?
Another issue is "physical log" if first modification after checkpoint
was from an aborted txn. Now because you need to write that physical log
page you will also need to write the abort to pg_log ...

I guess you can however discard heap tuple *column values* from aborted 
txns, but I am not sure that is worth it.

Andreas

Responses

pgsql-hackers by date

Next:From: Zeugswetter Andreas SBDate: 2001-07-06 14:08:34
Subject: AW: AW: Re: Backup and Recovery
Previous:From: Alex PilosovDate: 2001-07-06 13:45:22
Subject: Re: Proper use of select() parameter nfds?

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