On Thu, Dec 16, 2010 at 6:48 AM, Greg Smith wrote:
> I meant that I'd bundle it into the block of time I spend on that, and
> likely submit with something else that touches the same area. Obviously the
> correction patch would be better on its own when being handed over to a
> committer.
Oh, tha
Robert Haas wrote:
On Wed, Dec 15, 2010 at 9:22 AM, Greg Smith wrote:
patch I submit. Doesn't seem worth going through the trouble of committing
that minor rework on its own, I'll slip it into the next useful thing that
touches this area I do. Thanks for the hint, this would work better th
On Wed, Dec 15, 2010 at 9:22 AM, Greg Smith wrote:
> patch I submit. Doesn't seem worth going through the trouble of committing
> that minor rework on its own, I'll slip it into the next useful thing that
> touches this area I do. Thanks for the hint, this would work better than
> what I did.
W
Alvaro Herrera wrote:
I gave this patch a look and it seems pretty good to me, except that I'm
uncomfortable with the idea of mdsync filling in the details for
CheckpointStats fields directly. Would it work to pass a struct (say
SmgrSyncStats) from CheckPointBuffers to smgrsync and from there to
On Tue, Dec 14, 2010 at 11:47 AM, Alvaro Herrera
wrote:
>> > that I'm
>> > uncomfortable with the idea of mdsync filling in the details for
>> > CheckpointStats fields directly. Would it work to pass a struct (say
>> > SmgrSyncStats) from CheckPointBuffers to smgrsync and from there to
>> > mdsyn
Excerpts from Robert Haas's message of mar dic 14 11:34:55 -0300 2010:
> On Tue, Dec 14, 2010 at 9:29 AM, Alvaro Herrera
> wrote:
> > I gave this patch a look and it seems pretty good to me, except
>
> Err, woops. I just committed this as-is. Sorry.
I noticed :-)
> > that I'm
> > uncomfortabl
On Tue, Dec 14, 2010 at 9:29 AM, Alvaro Herrera
wrote:
> I gave this patch a look and it seems pretty good to me, except
Err, woops. I just committed this as-is. Sorry.
> that I'm
> uncomfortable with the idea of mdsync filling in the details for
> CheckpointStats fields directly. Would it wo
I gave this patch a look and it seems pretty good to me, except that I'm
uncomfortable with the idea of mdsync filling in the details for
CheckpointStats fields directly. Would it work to pass a struct (say
SmgrSyncStats) from CheckPointBuffers to smgrsync and from there to
mdsync, have this func
Robert Haas wrote:
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
wor
On Mon, Dec 13, 2010 at 3:19 AM, Greg Smith wrote:
> Robert Haas wrote:
>>
>> 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 i
Robert Haas wrote:
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 t
On Sun, Dec 5, 2010 at 4:23 PM, Greg Smith 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 do
Jeff Janes wrote:
In my test cases, the syncs that the backends were doing were almost
always to the same file that the checkpoint writer was already choking
on (so they are entangled simply by virtue of that). So very quickly
all the backends hit the same wall and thunked to a halt. This is
pr
On Sun, Dec 5, 2010 at 1:23 PM, Greg Smith 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 do
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 leng
On Tue, Nov 30, 2010 at 12:15 PM, Jeff Janes wrote:
> On Tue, Nov 30, 2010 at 8:38 AM, Greg Smith wrote:
>
>
> Hi Greg,
>
> Thanks for the update.
>
>
>
>> This might be ready for some proper review now. I know there's at least one
>> blatant bug still in here I haven't found yet, related to how
On Tue, Nov 30, 2010 at 8:38 AM, Greg Smith wrote:
Hi Greg,
Thanks for the update.
> This might be ready for some proper review now. I know there's at least one
> blatant bug still in here I haven't found yet, related to how the averages
> are computed.
Yes, the blatant bug:
average_sync_
2010/11/30 Greg Smith :
> Jeff Janes wrote:
>>
>> For the individual file sync times emitted under debug1, it would be
>> very handy if the file being synced was identified, for example
>> "relation base/16384/16523". Rather than being numbered sequentially
>> within a given checkpoint.
>>
>
> I wa
Jeff Janes wrote:
For the individual file sync times emitted under debug1, it would be
very handy if the file being synced was identified, for example
"relation base/16384/16523". Rather than being numbered sequentially
within a given checkpoint.
I was numbering them sequentially so that it'
Jeff Janes wrote:
For the individual file sync times emitted under debug1, it would be
very handy if the file being synced was identified, for example
"relation base/16384/16523".
I was in the middle of looking into adding that already, so consider
that part of the target for the next update I
On Wed, Nov 24, 2010 at 1:02 AM, Greg Smith wrote:
> Robert Haas wrote:
>> Did this get eaten by the email goblin, or you're still working on it?
>
> Fell behind due to an unfortunately timed bit of pneumonia. Hurray for the
> health benefits of cross country flights. Will fix this up, rebase my
Robert Haas wrote:
Did this get eaten by the email goblin, or you're still working on it?
Fell behind due to an unfortunately timed bit of pneumonia. Hurray for
the health benefits of cross country flights. Will fix this up, rebase
my other patch, and head toward some more review/'Fest c
On Mon, Nov 15, 2010 at 12:09 PM, Greg Smith wrote:
> So my task list is:
>
> 0) Rebase against the HEAD that just code related to this touched today
>
> 1) Assume that log_checkpoints is sufficient control over whether the timing
> overhead added is worth collecting, and therefore remove the half
On Mon, Nov 15, 2010 at 3:09 PM, Greg Smith wrote:
> So my task list is:
>
> 0) Rebase against the HEAD that just code related to this touched today
>
> 1) Assume that log_checkpoints is sufficient control over whether the timing
> overhead added is worth collecting, and therefore remove the half-
On Mon, Nov 15, 2010 at 2:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> I would be very surprised if we can find a system where gettimeofday()
>> takes a significant amount of time compared with fsync(). It might be
>> (probably is) too expensive to stick into code paths that are heavily
>> CP
So my task list is:
0) Rebase against the HEAD that just code related to this touched today
1) Assume that log_checkpoints is sufficient control over whether the
timing overhead added is worth collecting, and therefore remove the
half-baked idea of also wrapping with a compile-time option.
2
Robert Haas writes:
> I would be very surprised if we can find a system where gettimeofday()
> takes a significant amount of time compared with fsync(). It might be
> (probably is) too expensive to stick into code paths that are heavily
> CPU-bounded, but surely the cost here is going to be dwarf
On Sun, Nov 14, 2010 at 7:04 PM, Greg Smith wrote:
> It might. One trade-off is that if you're looking at the sync write detail,
> the summary comes out in a similar form. And it was easy to put in
> here--I'd have to return some new data out of the sync phase call in order
> for that to show up
Magnus Hagander wrote:
I think that it's reasonable for the sort of people who turn log_checkpoints
on to also get the sync summary line, thus it being logged at LOG level.
In that case, wouldn't it make more sense to add a couple of more
fields to the existing line? Easier to post-process
On Sun, Nov 14, 2010 at 22:37, Greg Smith wrote:
> Attached patch adds some logging for each individual fsync call made during
> a checkpoint, along with a summary at the end. You need to have the
> following to see all of the detail:
>
> log_checkpoints=on
> log_min_messages=debug1
>
> And here'
Attached patch adds some logging for each individual fsync call made
during a checkpoint, along with a summary at the end. You need to have
the following to see all of the detail:
log_checkpoints=on
log_min_messages=debug1
And here's a sample:
LOG: checkpoint starting: immediate force wait
31 matches
Mail list logo
