Re: Sync Rep Design
От | Hannu Krosing |
---|---|
Тема | Re: Sync Rep Design |
Дата | |
Msg-id | 4D1D8B2F.5070001@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Sync Rep Design (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Sync Rep Design
|
Список | pgsql-hackers |
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. of couse we could put a bitmap in the status update messages from slave and have some quorum on options on master for when the data is "in sync", say "need 5 received or (1 applied and 1 fsynced)", but I am pretty sure that trying to get anywhere with this before applying the basic sync rep patch would push back sync rep to at least 9.2 if not 9.5 --------------------- Hannu Krosing
В списке pgsql-hackers по дате отправления: