ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Surely this makes matters worse, not better. What happens near a segment
>> boundary crossing?
> Here is the dumped progres information by the attached patch
> (only for debug purpose).
Oh, I take that back. I
Heikki Linnakangas wrote:
Tom Lane wrote:
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
- ((double) (int32) (recptr.xrecoff -
ckpt_start_recptr.xrecoff)) / XLogSegSize) /
+ ((double) recptr.xrecoff - (double)
ckpt_start_recptr.xrecoff) / XLogSegSize) /
Surely this makes matter
Tom Lane wrote:
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
-((double) (int32) (recptr.xrecoff -
ckpt_start_recptr.xrecoff)) / XLogSegSize) /
+((double) recptr.xrecoff - (double) ckpt_start_recptr.xrecoff)
/ XLogSegSize) /
Surely this makes matters worse, not
Tom Lane <[EMAIL PROTECTED]> wrote:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > -((double) (int32) (recptr.xrecoff -
> > ckpt_start_recptr.xrecoff)) / XLogSegSize) /
> > +((double) recptr.xrecoff - (double) ckpt_start_recptr.xrecoff)
> > / XLogSegSize) /
>
> Sure
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> - ((double) (int32) (recptr.xrecoff -
> ckpt_start_recptr.xrecoff)) / XLogSegSize) /
> + ((double) recptr.xrecoff - (double) ckpt_start_recptr.xrecoff)
> / XLogSegSize) /
Surely this makes matters worse, not better. What h
I run long DBT-2 with 8.3beta2 and saw checkpoint spikes periodically.
The progress against WAL segments consumption *jumped up* in such cases.
It seems to be a miscalculation in IsCheckpointOnSchedule().
xrecoff is uint32, therefore the difference of two xrecoffs could
be between -4G and +4G. We
