> > 1) To deal with partial/inconsisitent write to the data file at
> > recovery, we need full page writes at the first modification to
> > after each checkpoint. It consumes much of WAL space.
> We need to find a way around this someday. Other DBs don't
> do this; it may be becuase they're less durable, or because
> they fixed the problem.
They eighter can only detect a failure later (this may be a very long
time depending on access and verify runs) or they also write page
images. Those that write page images usually write "before images" to a
different area that is cleared periodically (e.g. during checkpoint).
Writing to a different area was considered in pg, but there were more
negative issues than positive.
So imho pg_compresslog is the correct path forward. The current
discussion is only about whether we want a more complex pg_compresslog
and no change to current WAL, or an increased WAL size for a less
Both would be able to compress the WAL to the same "archive log" size.
In response to
pgsql-hackers by date
|Next:||From: Dave Page||Date: 2007-04-25 08:03:41|
|Subject: Buildfarm: Stage logs not available for MSVC builds|
|Previous:||From: Jeremy Drake||Date: 2007-04-25 06:48:30|
|Subject: Re: tsearch2 in 8.3|
pgsql-patches by date
|Next:||From: ITAGAKI Takahiro||Date: 2007-04-25 08:27:15|
|Subject: autovacuum does not start in HEAD|
|Previous:||From: Tom Lane||Date: 2007-04-24 21:10:33|
|Subject: Re: SPI_psprintf and SPI_pstrdup |