Re: Sync Rep Design

On Fri, 2010-12-31 at 12:06 +0200, Heikki Linnakangas wrote:
> 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(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.
>
> Agreed, it feels natural to specify when a piece of WAL is acknowledged
> in the standby.

That can also be done, its not a problem.

Many people asked for just "on" or "off".

Currently "on" <--> "slave has fsynced" WAL.

> 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.

The parameter on the standby affects the behaviour of the standby. The
standby is saying "don't pick me, I'm not a good target".

--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services