Re: Sync Rep Design
От | Heikki Linnakangas |
---|---|
Тема | Re: Sync Rep Design |
Дата | |
Msg-id | 4D1DAB14.5000800@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Sync Rep Design (Hannu Krosing <hannu@2ndquadrant.com>) |
Ответы |
Re: Sync Rep Design
Re: Sync Rep Design Re: Sync Rep Design |
Список | pgsql-hackers |
On 31.12.2010 09:50, Hannu Krosing wrote: > On 30.12.2010 22:27, Robert Haas wrote: >> On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs<simon@2ndquadrant.com> >> wrote: >>> synchronous_replication (boolean) >>> Specifies whether transaction commit will wait for WAL records >>> to be replicated before the command returns a "success" >>> indication to the client. >> The word "replicated" here could be taken to mean different things, >> most obviously: >> >> - slave has received the WAL >> - slave has fsync'd the WAL >> - slave has applied the WAL > Perhaps the level of "replication guarantee" should be decided on the > slave side, by > having a configuration parameter there > > report_as_replicated = received|written_to_disk|fsynced|applied > > for different types of hosts may have wildly different guarantees and > performance > parameters for these. One could envision a WAL-archive type "standby" > which is > there for data persistence only will and never "apply" WAL. Agreed, it feels natural to specify when a piece of WAL is acknowledged in the standby. Regarding the rest of the proposal, I would still prefer the UI discussed here: http://archives.postgresql.org/message-id/4CAE030A.2060701@enterprisedb.com It ought to be the same amount of work to implement, and provides the same feature set, but makes administration a bit easier by being able to name the standbys. Also, I dislike the idea of having the standby specify that it's a synchronous standby that the master has to wait for. Behavior on the master should be configured on the master. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: