Re: Core team statement on replication in PostgreSQL

From: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, Douglas McNaught <doug(at)mcnaught(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, David Fetter <david(at)fetter(dot)org>, 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-06-01 20:16:51
Message-ID: 484303B3.10109@mansionfamily.plus.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

Aidan Van Dyk wrote:
> The whole single-threaded WAL replay problem is going to rear it's ugly
> head here too, and mean that a slave *won't* be able to keep up with a
> busy master if it's actually trying to apply all the changes in
> real-time.
Is there a reason to commit at the same points that the master
committed? Wouldn't relaxing
that mean that at least you would get 'big' commits and some economy of
scale? It might
not be too bad. All I can say is that Sybase warm standby is useful,
even though the rep
for an update that changes a hundred rows is a hundred updates keyed on
primary key,
which is pretty sucky in terms of T-SQL performance.

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Hannu Krosing 2008-06-01 20:42:11 Re: Core team statement on replication in PostgreSQL
Previous Message James Mansion 2008-06-01 19:57:00 Re: Core team statement on replication in PostgreSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2008-06-01 20:42:11 Re: Core team statement on replication in PostgreSQL
Previous Message James Mansion 2008-06-01 19:57:00 Re: Core team statement on replication in PostgreSQL