Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait
Date
Msg-id 20170120013529.md5o2wovaojqtm2q@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait  (Stephen Frost <sfrost@snowman.net>)
List 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 by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait
Next
From: Peter Geoghegan
Date:
Subject: [HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1