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
|
Список | 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 по дате отправления: