Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait
Дата
Msg-id 20170120013529.md5o2wovaojqtm2q@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On 2017-01-19 10:06:09 -0500, Stephen Frost wrote:
> WAL replay does do more work, generally speaking (the WAL has to be
> read, the checksum validated on it, and then the write has to go out,
> while the checkpointer just writes the page out from memory), but it's
> also dealing with less contention on the system (there aren't a bunch of
> backends hammering the disks to pull data in with reads when you're
> doing crash recovery...).

There's a huge difference though: WAL replay is single threaded, whereas
generating WAL is not.  Especially if there's synchronous IO required
(most commonly reading in data, because more data was modified in the
current checkpointthan fit in shared buffers, so FPIs don't pre-fill
buffers), you can be significantly slower than generating the WAL.
Especially when you deal with SSDs, which can handle a lot of IO in
parallel, you can easily run into such issues.

Greetings,

Andres Freund



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait
Следующее
От: Peter Geoghegan
Дата:
Сообщение: [HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1