Re: checkpointer continuous flushing

Hello,

Attached is very minor v5 update which does a rebase & completes the 
cleanup of doing a full sort instead of a chuncked sort.

>> Attached is an updated version of the patch which turns the sort option 
>> into a boolean, and also include the sort time in the checkpoint log.
>> 
>> There is still an open question about whether the sorting buffer allocation 
>> is lost on some signals and should be reallocated in such event.
>
> In such case, probably the allocation should be managed from 
> CheckpointerMain, and the lazy allocation could remain for other callers (I 
> guess just "initdb").
>
>
> More open questions:
>
> - best name for the flush option (checkpoint_flush_to_disk,
>     checkpoint_flush_on_write, checkpoint_flush, ...)
>
> - best name for the sort option (checkpoint_sort,
>     checkpoint_sort_buffers, checkpoint_sort_ios, ...)
>
>
> Other nice-to-have inputs:
>
> - tests on a non-linux system with posix_fadvise
>   (FreeBSD? others?)
>
> - tests on a large dedicated box
>
>
> Attached are some scripts to help with testing, if someone's feels like that:
>
> - cp_test.sh: run some tests, to adapt to one's setup...
>
> - cp_test_count.pl: show percent of late transactions
>
> - avg.py: show stats about stuff
>
>   sh> grep 'progress: ' OUTPUT_FILE | cut -d' ' -f4 | avg.py
>
>   *BEWARE* that if pgbench got stuck some "0" data are missing,
>   look for the actual tps in the output file and for the line
>   count to check whether it is the case... some currently submitted
>   patch on pgbench helps, see https://commitfest.postgresql.org/5/199/

As this pgbench patch is now in master, pgbench is less likely to get 
stuck, but check nevertheless that the number of progress line matches the 
expected number.

-- 
Fabien.