Re: COMMIT NOWAIT Performance Option - Mailing list pgsql-hackers

From Zeugswetter Andreas ADI SD
Subject Re: COMMIT NOWAIT Performance Option
Date
Msg-id E1539E0ED7043848906A8FF995BDA57901CAFF11@m0143.s-mxs.net
Whole thread Raw
In response to Re: COMMIT NOWAIT Performance Option  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: COMMIT NOWAIT Performance Option  (Gregory Stark <stark@enterprisedb.com>)
List 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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Postgres Replication
Next
From: Gregory Stark
Date:
Subject: Re: COMMIT NOWAIT Performance Option