Re: checkpointer continuous flushing - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: checkpointer continuous flushing
Date
Msg-id alpine.DEB.2.10.1506030738430.20439@sto
Whole thread Raw
In response to Re: checkpointer continuous flushing  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: checkpointer continuous flushing  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List 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 by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: checkpointer continuous flushing
Next
From: Fabien COELHO
Date:
Subject: Re: checkpointer continuous flushing