Re: WAL & SHM principles

Поиск
Список
Период
Сортировка
От ncm@zembu.com (Nathan Myers)
Тема Re: WAL & SHM principles
Дата
Msg-id 20010312164550.Q624@store.zembu.com
обсуждение исходный текст
Ответ на RE: WAL & SHM principles  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL on multi-CPU systems
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Do we still need PowerPC-specific timestamp_is_current/epoch?