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

Re: Core team statement on replication in PostgreSQL

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: "David Fetter" <david(at)fetter(dot)org>
Cc: "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 15:40:57
Message-ID: e51f66da0805290840j71bfaaam70ff3a4054f22440@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
On 5/29/08, David Fetter <david(at)fetter(dot)org> wrote:
> On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote:
>  > 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.)
>
> This part is a deal-killer.  It's a giant up-hill slog to sell warm
>  standby to those in charge of making resources available because the
>  warm standby machine consumes SA time, bandwidth, power, rack space,
>  etc., but provides no tangible benefit, and this feature would have
>  exactly the same problem.
>
>  IMHO, without the ability to do read-only queries on slaves, it's not
>  worth doing this feature at all.

I would not be so harsh - I'd like to have the lossless standby even
without read-only slaves.

But Tom's mail gave me impression core wants to wait until we get "perfect"
read-only slave implementation so we wait with it until 8.6, which does
not seem sensible.  If we can do slightly inefficient (but simple)
implementation
right now, I see no reason to reject it, we can always improve it later.

Especially as it can be switchable.  And we could also have
transaction_timeout paramenter on slaves so the hit on master is limited.

-- 
marko

In response to

Responses

pgsql-hackers by date

Next:From: JustinDate: 2008-05-29 15:45:10
Subject: Re: [PERFORM] Memory question on win32 systems
Previous:From: Guillaume SmetDate: 2008-05-29 15:23:15
Subject: Re: Upcoming back-branch update releases

pgsql-advocacy by date

Next:From: Joshua D. DrakeDate: 2008-05-29 15:46:22
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: David FetterDate: 2008-05-29 15:21:05
Subject: Re: Core team statement on replication in PostgreSQL

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