Re: Geographic High-Availability/Replication

From: Decibel! <decibel(at)decibel(dot)org>
To: Markus Schiltknecht <markus(at)bluegap(dot)ch>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: Geographic High-Availability/Replication
Date: 2007-08-29 00:24:21
Message-ID: 20070829002421.GQ1386@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Aug 24, 2007 at 06:54:35PM +0200, Markus Schiltknecht wrote:
> Gregory Stark wrote:
> >Only if your application is single-threaded. By single-threaded I don't
> >refer
> >to operating system threads but to the architecture. If you're processing a
> >large batch file handling records one by one and waiting for each commit
> >before proceeding then it's single threaded. If you have a hundred
> >independent
> >clients on separate connections doing separate things then each one of them
> >could get 6tps. Which you have will depend on your application and your
> >needs,
> >it may not be something you can change.
>
> Correct.
>
> Plus, as in the implementation of Postgres-R, performance is *not* bound
> to the slowest node. Instead, every node can process transactions at
> it's own speed. Slower nodes might then have to queue transactions from
> those until they catch up again.

But is the complete transaction information safely stored on all nodes
before a commit returns?
--
Decibel!, aka Jim Nasby decibel(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message D. Dante Lorenso 2007-08-29 00:24:42 Re: Is there a better way to do this?
Previous Message Decibel! 2007-08-29 00:16:20 Re: Seeking datacenter PITR backup procedures [RESENDING]