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

Re: beta testing version

From: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: beta testing version
Date: 2000-12-01 07:06:31
Message-ID: 006501c05b65$3c442fa0$b67a30d0@sectorbase.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> As for replaying logs against a restored snapshot dump... AIUI, a 
> dump records tuples by OID, but the WAL refers to TIDs.  Therefore, 
> the WAL won't work as a re-do log to recover your transactions 
> because the TIDs of the restored tables are all different.   

True for current way of backing up - ie saving data in "external"
(sql) format. But there is another way - saving data files in their
natural (binary) format. WAL records may be applyed to
such dump, right?

> To get replaying we need an "update log", something that might be

What did you mean by "update log"?
Are you sure that WAL is not "update log" ? -:)

> in 7.2 if somebody does a lot of work.
> 
> > Note I'm not saying you're wrong, just asking that you explain your
> > comment a little more. If WAL can't be used to help recover from
> > crashes where database corruption occurs, what good is it?
> 
> The WAL is a performance optimization for the current recovery
> capabilities, which assume uncorrupted table files.  It protects
> against those database server crashes that happen not to corrupt 
> the table files (i.e. most).  It doesn't protect against corruption 
> of the tables, by bugs in PG or in the OS or from "hardware events".  
> It also doesn't protect against OS crashes that result in 
> write-buffered sectors not having been written before the crash.  
> Practically, this means that WAL file entries older than a few 
> seconds are not useful for much.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Even now, without BAR, WAL entries become unuseful only after checkpoints
(and I wouldn't recomend to create them each few seconds -:)). WAL based
BAR will require archiving of log records.

Vadim



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-12-01 07:16:39
Subject: Re: Operators and commutation
Previous:From: Alex PilosovDate: 2000-12-01 06:54:23
Subject: Re: beta testing version

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