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

Re: [HACKERS] Full page writes improvement, code update

From: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Cc: "Koichi Suzuki" <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp>,<pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Full page writes improvement, code update
Date: 2007-04-25 08:00:16
Message-ID: E1539E0ED7043848906A8FF995BDA57901F40143@m0143.s-mxs.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
> > 1) To deal with partial/inconsisitent write to the data file at
crash 
> > recovery, we need full page writes at the first modification to
pages
> > 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
complex implementation.
Both would be able to compress the WAL to the same "archive log" size.

Andreas

In response to

Responses

pgsql-hackers by date

Next:From: Dave PageDate: 2007-04-25 08:03:41
Subject: Buildfarm: Stage logs not available for MSVC builds
Previous:From: Jeremy DrakeDate: 2007-04-25 06:48:30
Subject: Re: tsearch2 in 8.3

pgsql-patches by date

Next:From: ITAGAKI TakahiroDate: 2007-04-25 08:27:15
Subject: autovacuum does not start in HEAD
Previous:From: Tom LaneDate: 2007-04-24 21:10:33
Subject: Re: SPI_psprintf and SPI_pstrdup

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