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

Re: COMMIT NOWAIT Performance Option

From: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
To: "Jeff Davis" <pgsql(at)j-davis(dot)com>,"Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>,"Gregory Stark" <stark(at)enterprisedb(dot)com>,"Josh Berkus" <josh(at)agliodbs(dot)com>,<pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Subject: Re: COMMIT NOWAIT Performance Option
Date: 2007-03-01 09:45:42
Message-ID: E1539E0ED7043848906A8FF995BDA57901CAFF11@m0143.s-mxs.net (view raw or flat)
Thread:
Lists: pgsql-hackers
> Under normal operations, shutting down the database does a 
> checkpoint, right? So unless you're in recovery mode, there's 
> no additional cost.
> And I can't think of any reason you'd need to see any pages 
> before the last checkpoint (unless you don't trust your disk 
> and just want to check all the pages, which is more than we 
> can do now anyway).

The problem is you don't necessarily have the info which pages changed
*after* the last checkpoint. Especially since in the mentioned scenario
you don't have full-page images. Maybe a suitable replacement for
full-page would be to sync the first WAL record for a page change before
writing the buffer (startup recovery would then check all pages it
touches). This syncing does not sound promising though.

And it is also not only one page we are looking for, but one per
controller (for battery backed) or one per phys disk.

Andreas

In response to

Responses

pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-03-01 10:04:20
Subject: Re: COMMIT NOWAIT Performance Option
Previous:From: Andrew DunstanDate: 2007-03-01 09:21:58
Subject: Re: Postgres Replication

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