From: | Hannu Krosing <hannu(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Sync Rep Design |
Date: | 2010-12-31 07:50:07 |
Message-ID: | 4D1D8B2F.5070001@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30.12.2010 22:27, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs<simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2010-12-31 07:50:43 | Re: Sync Rep Design |
Previous Message | Noah Misch | 2010-12-31 05:47:46 | Re: Avoiding rewrite in ALTER TABLE ALTER TYPE |