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

Re: Core team statement on replication in PostgreSQL

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, David Fetter <david(at)fetter(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-05-30 00:31:31
Message-ID: Pine.GSO.4.64.0805292012520.16207@westnet.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
On Thu, 29 May 2008, Tom Lane wrote:

> There's no point in having read-only slave queries if you don't have a 
> trustworthy method of getting the data to them.

This is a key statement that highlights the difference in how you're 
thinking about this compared to some other people here.  As far as some 
are concerned, the already working log shipping *is* a trustworthy method 
of getting data to the read-only slaves.  There are plenty of applications 
(web oriented ones in particular) where if you could direct read-only 
queries against a slave, the resulting combination would be a giant 
improvement over the status quo even if that slave was as much as 
archive_timeout behind the master.  That quantity of lag is perfectly fine 
for a lot of the same apps that have read scalability issues.

If you're someone who falls into that camp, the idea of putting the sync 
replication job before the read-only slave one seems really backwards.

I fully accept that it may be the case that it doesn't make technical 
sense to tackle them in any order besides sync->read-only slaves because 
of dependencies in the implementation between the two.  If that's the 
case, it would be nice to explicitly spell out what that was to deflect 
criticism of the planned prioritization.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

pgsql-hackers by date

Next:From: Aidan Van DykDate: 2008-05-30 00:57:21
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Merlin MoncureDate: 2008-05-30 00:25:10
Subject: Re: Core team statement on replication in PostgreSQL

pgsql-advocacy by date

Next:From: Aidan Van DykDate: 2008-05-30 00:57:21
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Merlin MoncureDate: 2008-05-30 00:25:10
Subject: Re: Core team statement on replication in PostgreSQL

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