Skip site navigation (1) Skip section navigation (2)

Re: Core team statement on replication in PostgreSQL

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Dave Page <dpage(at)pgadmin(dot)org>,Douglas McNaught <doug(at)mcnaught(dot)org>,"Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>,David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-05-29 16:35:41
Message-ID: 20080529163541.GE27560@yugib.highrise.ca (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
* Marko Kreen <markokr(at)gmail(dot)com> [080529 12:27]:

> I don't think thats a problem.  If the user runs its server at the
> limit of write-bandwidth, thats its problem.
> 
> IOW, with synchronous replication, we _want_ the server to lag behind
> slaves.
> 
> About the single-threading problem - afaik, the replay is mostly I/O bound
> so threading would not buy you much.

Right - the problem is that the master has N>1 backends working away,
preloading the modified heap pages into shared buffers, where they are
modified w/ WAL.  This means the kernel/controller has man read-requests
in flight at a time as the modifies/writes chug along.  The slave has to
read/modify/write every buffer, one at a time, as WAL arrives, meaning
there is ever only 1 IO request in flight at a time.

So the server as a queue of many parallel reads going on, the slave has
a set of sequential random reads going on.

a.
-- 
Aidan Van Dyk                                             Create like a god,
aidan(at)highrise(dot)ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-05-29 16:40:14
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Joshua D. DrakeDate: 2008-05-29 16:29:58
Subject: Re: Core team statement on replication in PostgreSQL

pgsql-advocacy by date

Next:From: Tom LaneDate: 2008-05-29 16:40:14
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Joshua D. DrakeDate: 2008-05-29 16:32:22
Subject: Re: State of PostgreSQL, BOF at OSCON?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group