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

Re: Core team statement on replication in PostgreSQL

From: Mathias Brossard <mathias(dot)brossard(at)opentrust(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-05-29 16:01:44
Message-ID: 483ED368.5090408@opentrust.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
Tom Lane wrote:
> In practice, simple asynchronous single-master-multiple-slave
> replication covers a respectable fraction of use cases, so we have
> concluded that we should allow such a feature to be included in the core
> project.  We emphasize that this is not meant to prevent continued
> development of add-on replication projects that cover more complex use
> cases.

IMHO, this will help PostgreSQL adoption, mindshare and even boost interest in 
development for the other replication use cases.

> We believe that the most appropriate base technology for this is
> probably real-time WAL log shipping, as was demoed by NTT OSS at PGCon.

The slides are up at http://www.pgcon.org/2008/schedule/events/76.en.html
 From what I gather from those slides it seems to me that the NTT solution is 
synchronous not asynchronous. In my opinion it's even better, but I do 
understand that others might prefer asynchronous. I'm going to speculate, but I 
would think it should be possible (without a substancial rewrite) to support 
both modes (or even some intermediate modes, like DRBD on Linux).

> We hope that such a feature can be completed for 8.4.  Ideally this
> would be coupled with the ability to execute read-only queries on the
> slave servers, but we see technical difficulties that might prevent that
> from being completed before 8.5 or even further out.  (The big problem
> is that long-running slave-side queries might still need tuples that are
> vacuumable on the master, and so replication of vacuuming actions would
> cause the slave's queries to deliver wrong answers.)

 From the 8.4dev documentation, another problem for read-only slaves would be :
« Operations on hash indexes are not presently WAL-logged, so replay will not 
update these indexes. The recommended workaround is to manually REINDEX  each 
such index after completing a recovery operation. ».

Sincerely,
-- 
Mathias Brossard

Attachment: mathias_brossard.vcf
Description: text/x-vcard (191 bytes)

In response to

Responses

pgsql-hackers by date

Next:From: Dave PageDate: 2008-05-29 16:03:06
Subject: Re: [PERFORM] Memory question on win32 systems
Previous:From: Dave PageDate: 2008-05-29 16:00:55
Subject: Re: Core team statement on replication in PostgreSQL

pgsql-advocacy by date

Next:From: Selena DeckelmannDate: 2008-05-29 16:03:15
Subject: Re: State of PostgreSQL, BOF at OSCON?
Previous:From: Dave PageDate: 2008-05-29 16:00:55
Subject: Re: Core team statement on replication in PostgreSQL

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