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.