On Sun, Dec 5, 2010 at 4:23 PM, Greg Smith <g...@2ndquadrant.com> wrote: > Jeff Janes wrote: >> >> I've attached a tiny patch to apply over yours, to deal with this and >> with the case where no files are synced. >> > > Thanks for that. That obvious error eluded me because in most of the patch > update testing I was doing (on ext3), the longest sync was always about the > same length as the total sync time. > > Attached patch (in correct diff form this time!) collects up all changes. > That includes elimination of a potential race condition if someone changes > log_checkpoints while a long sync phase is executing. I don't know whether > that can happen, and it obviously won't give accurate stats going back to > the beginning of the checkpoint in that case, but it tries to defend aginst > producing complete garbage if that value changes out from under it. > > This is the first version of this patch I feel fairly good about; no open > concerns left on my side. Jeff, since you're now the de-facto credited > reviewer of this one by virtue of suggesting bug fixes, could you take this > update out for a spin too?
I took a look at this and it looks generally good, but I'm wondering why md.c is converting the results from an exact value to a floating point, only to have xlog.c turn around and convert back to an integer. I think it could just return milliseconds directly, or if you're worried about a checkpoint that takes more than 24 days to complete, seconds and microseconds. Or am I missing something? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
