Re: initdb and fsync

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: initdb and fsync
Дата
Msg-id 1328468000.15224.32.camel@jdavis
обсуждение исходный текст
Ответ на Re: initdb and fsync  (Noah Misch <noah@leadboat.com>)
Ответы Re: initdb and fsync  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: initdb and fsync  (Noah Misch <noah@leadboat.com>)
Re: initdb and fsync  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On Sat, 2012-02-04 at 20:18 -0500, Noah Misch wrote:
> If we add fsync calls to the initdb process, they should cover the entire data
> directory tree.  This patch syncs files that initdb.c writes, but we ought to
> also sync files that bootstrap-mode backends had written.

It doesn't make sense for initdb to take responsibility to sync files
created by the backend. If there are important files that the backend
creates, it should be the backend's responsibility to fsync them (and
their parent directory, if needed). And if they are unimportant to the
backend, then there is no reason for initdb to fsync them.

> An optimization
> like the pg_flush_data() call in copy_file() may reduce the speed penalty.

That worked pretty well. It took it down about 100ms on my machine,
which closes the gap significantly.

> initdb should do these syncs by default and offer an option to disable them.

For test frameworks that run initdb often, that makes sense.

But for developers, it doesn't make sense to spend 0.5s typing an option
that saves you 0.3s. So, we'd need some more convenient way to choose
the no-fsync option, like an environment variable that developers can
set. Or maybe developers don't care about 0.3s?

Regards,Jeff Davis



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: basic pgbench runs with various performance-related patches
Следующее
От: Jan Urbański
Дата:
Сообщение: pl/python long-lived allocations in datum->dict transformation