Re: Avoiding adjacent checkpoint records
От | Simon Riggs |
---|---|
Тема | Re: Avoiding adjacent checkpoint records |
Дата | |
Msg-id | CA+U5nM+S0Sj=nrqFVBA7knRrLqvLFNSDidM1vML03uGogbyDNg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Avoiding adjacent checkpoint records ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Avoiding adjacent checkpoint records
|
Список | pgsql-hackers |
On 7 June 2012 14:59, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> there is no guarantee that we'll manage to reach a database state >> that is consistent with data already flushed out to disk during >> the last checkpoint. > > Robert Haas <robertmhaas@gmail.com> wrote: > >> I know of real customers who would have suffered real data loss >> had this code been present in the server version they were using. >> Checkpoints are the *only* mechanism by which SLRU pages get >> flushed to disk on a mostly-idle system. That means if something >> happens to your pg_xlog directory, and you haven't had a >> checkpoint, you're screwed. If that is the concern, then its a one line fix to add the missing clog flush. The other suggestions I've skim read seem fairly invasive at this stage of the release. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: