Re: WAL & SHM principles - Mailing list pgsql-hackers

From ncm@zembu.com (Nathan Myers)
Subject Re: WAL & SHM principles
Date
Msg-id 20010312164550.Q624@store.zembu.com
Whole thread Raw
In response to RE: WAL & SHM principles  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
List pgsql-hackers
Sorry for taking so long to reply...

On Wed, Mar 07, 2001 at 01:27:34PM -0800, Mikheev, Vadim wrote:
> Nathan wrote:
> > It is possible to build a logging system so that you mostly don't care
> > when the data blocks get written    [after being changed, as long as they get written by an fsync];
> > a particular data block on disk is 
> > considered garbage until the next checkpoint, so that you 
> 
> How to know if a particular data page was modified if there is no
> log record for that modification?
> (Ie how to know where is garbage? -:))

In such a scheme, any block on disk not referenced up to (and including) 
the last checkpoint is garbage, and is either blank or reflects a recent 
logged or soon-to-be-logged change.  Everything written (except in the 
log) after the checkpoint thus has to happen in blocks not otherwise 
referenced from on-disk -- except in other post-checkpoint blocks.

During recovery, the log contents get written to those pages during
startup. Blocks that actually got written before the crash are not
changed by being overwritten from the log, but that's ok. If they got
written before the corresponding log entry, too, nothing references
them, so they are considered blank.

> > might as well allow the blocks to be written any time,
> > even before the log entry.
> 
> And what to do with index tuples pointing to unupdated heap pages
> after that?

Maybe index pages are cached in shm and copied to mmapped blocks 
after it is ok for them to be written.

What platforms does PG run on that don't have mmap()?

Nathan Myers
ncm@zembu.com


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL on multi-CPU systems
Next
From: Tatsuo Ishii
Date:
Subject: Re: Do we still need PowerPC-specific timestamp_is_current/epoch?