Re: checkpointer continuous flushing

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: checkpointer continuous flushing
Дата
Msg-id alpine.DEB.2.10.1506030738430.20439@sto
обсуждение исходный текст
Ответ на Re: checkpointer continuous flushing  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: checkpointer continuous flushing
Список pgsql-hackers
Hello Amit,

>> It is currently "*_flush_to_disk". In Andres Freund version the name is
>> "sync_on_checkpoint_flush", but I did not found it very clear. Using
>> "*_flush_on_write" instead as your suggest, would be fine as well, it
>> emphasizes the "when/how" it occurs instead of the final "destination", why
>> not...
> [...]
>
> It seems 'sync' gets closer to what I really wanted 'flush' to mean. If 
> I understand this and the previous discussion(s) correctly, the patch 
> tries to alleviate the problems caused by one-big-sync-at-the 
> end-of-writes by doing the sync in step with writes (which do abide by 
> the checkpoint_completion_target). Given that impression, it seems 
> *_sync_on_write may even do the job.

I desagree with this one, because the sync is only *initiated*, not done. 
For this reason I think that "flush" seems a better word. I understand 
"sync" as "committed to disk". For the data to be synced, it should call 
with the "wait after" option, which is a partial "fsync", but that would 
be terrible for performance as all checkpointed pages would be written one 
by one, without any opportunity for reordering them.

For what it's worth and for the record, Linux sync_file_range 
documentation says "This is an asynchronous flush-to-disk operation" to 
describe the corresponding option. This is probably where I took it.

So two contenders:
  *_flush_to_disk  *_flush_on_write

-- 
Fabien.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: checkpointer continuous flushing
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: checkpointer continuous flushing