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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-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

Browse pgsql-advocacy by date

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

Browse pgsql-hackers by date

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