Background writer committed

Поиск
Список
Период
Сортировка
I committed the first part of the background writer process. We had a 
consensus on attempting to avoid write() calls from regular backends, 
but did no come to any conclusions what to do to force the kernel to 
actually do some IO.

Consequently, this patch is a separate process launched by postmaster, 
that periodically write()'s out "some" dirty buffers in LRU order. This 
causes the buffers returned for replacement (when a backend needs to 
read in a page) to be clean allways. The process does no sync(), fsync() 
or any other calls thus far. Nothing has changed in the checkpoint logic 
either.

The configuration options controlling the process are all PGC_SIGHUP:

# - Background writer -
#bgwriter_delay = 200       # 10-5000 milliseconds
#bgwriter_percent = 1       # 0-100% of dirty buffers
#bgwriter_maxpages = 100    # 1-1000 buffers max at once

Delay is the number of milliseconds to wait between loops. If there was 
nothing to do at all in one loop (all buffers clean), then the process 
will sleep for 10 seconds.

Percent is the percentage of "dirty pages" to write per loop. This is 
independant of the size of the buffer pool. If percent = 0 the 
postmaster will not start the process at all.

Maxpages is an upper bound to prevent the background writer from 
producing a write storm if a sequential operation causes all pages of a 
large buffer pool to be dirtied at once.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: ECPG: "EXEC SQL CREATE SCHEMA foo" Broken
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Build farm