Re: checkpointer continuous flushing - V18

>> ISTM that "progress" and "progress_slice" only depend on num_scanned and
>> per-tablespace num_to_scan and total num_to_scan, so they are somehow
>> redundant and the progress could be recomputed from the initial figures
>> when needed.
>
> They don't cause much space usage, and we access the values frequently. 
> So why not store them?

The same question would work the other way around: these values are one 
division away, why not compute them when needed? No big deal.

> [...] Given realistic amounts of memory the max potential "skew" seems 
> fairly small with float8. If we ever flush one buffer "too much" for a 
> tablespace it's pretty much harmless.

I do agree. I'm suggesting that a comment should be added to justify why 
float8 accuracy is okay.

>> I see a binary_heap_allocate but no corresponding deallocation, this
>> looks like a memory leak... or is there some magic involved?
>
> Hm. I think we really should use a memory context for all of this - we
> could after all error out somewhere in the middle...

I'm not sure that a memory context is justified here, there are only two 
mallocs and the checkpointer works for very long times. I think that it is 
simpler to just get the malloc/free right.

> [...] I'm not arguing for ripping it out, what I mean is that we don't 
> set a nondefault value for the GUCs on platforms with just 
> posix_fadivise available...

Ok with that.

-- 
Fabien.