Horton

Re: Spread checkpoint sync

Alvaro Herrera <alvherre@commandprompt.com>

View thread
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Rob Wultsch <wultsch@gmail.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Jeff Janes <jeff.janes@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-12-07T02:26:28Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add new buffers_backend_fsync field to pg_stat_bgwriter.

Excerpts from Greg Smith's message of dom dic 05 20:02:48 -0300 2010:

> When ends up happening if you push toward fully sync I/O is the design 
> you see in some other databases, where you need multiple writer 
> processes.  Then requests for new pages can continue to allocate as 
> needed, while keeping any one write from blocking things.  That's one 
> sort of a way to simulate asynchronous I/O, and you can substitute true 
> async I/O instead in many of those implementations.  We didn't have much 
> luck with portability on async I/O when that was last experimented with, 
> and having multiple background writer processes seems like overkill; 
> that whole direction worries me.

Why would multiple bgwriter processes worry you?

Of course, it wouldn't work to have multiple processes trying to execute
a checkpoint simultaneously, but what if we separated the tasks so that
one process is in charge of checkpoints, and another oneZis in charge of
the LRU scan?

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support