Re: Sync Rep Design

Поиск
Список
Период
Сортировка
От Marti Raudsepp
Тема Re: Sync Rep Design
Дата
Msg-id AANLkTikcji+2VuE95y0rgwD3bTjK5wSLAJuPwRUFfE81@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Sync Rep Design  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Sync Rep Design  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Most of your doc uses the terms "primary" and "standby", but a few
instances of "master" and "slave" have slipped in. I think it's better
to stick to consistent terminology.

On Thu, Dec 30, 2010 at 21:04, Simon Riggs <simon@2ndquadrant.com> wrote:
> With synchronous replication options specified at the application level
> (on the master) we can offer sync rep for the most important changes,
> without slowing down the bulk of the total workload. Application level
> options are an important and practical tool for allowing the benefits of
> synchronous replication for high performance applications. This feature
> is unique to PostgreSQL.

I think a comment about the "head-of-line blocking" nature of
streaming repliaction is in order. If you execute massive writes in
async mode and then run a transaction in sync mode, its commit will be
delayed until all the async transactions before it have been applied
on the slave.

> synchronous_replication_timeout (boolean)

Doesn't look like a boolean to me :)

Regards,
Marti


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Treat
Дата:
Сообщение: Re: Sync Rep Design
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: estimating # of distinct values