Re: Streaming replication, and walsender during recovery

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication, and walsender during recovery
Date: 2010-01-28 18:05:40
Message-ID: 18300.1264701940@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Thu, 2010-01-28 at 11:41 -0500, Tom Lane wrote:
>> FWIW, I don't agree with that prioritization in the least. Cascading
>> is something we could leave till 9.1, or even later, and

> Not what you said just a few days ago.

Me? I don't recall having said a word about cascading before.

> I'm a little worried the feature set of streaming rep isn't any better
> than what we have already.

Nonsense. Getting rid of the WAL-segment-based shipping delays is a
quantum improvement --- it means we actually have something approaching
real-time replication, which was really impractical before. Whether you
can feed slaves indirectly is just a minor administration detail. Yeah,
I know in some situations it could be helpful for performance, but
it's not even in the same ballpark of must-have-ness.

(Anyway, the argument that it's important for performance is pure
speculation AFAIK, untainted by any actual measurements. Given the lack
of optimization of WAL replay, it seems entirely possible that the last
thing you want to burden a slave with is sourcing data to more slaves.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-01-28 18:06:54 Re: quoting psql varible as identifier
Previous Message Tom Lane 2010-01-28 17:49:20 Re: plperl compiler warning