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<si...@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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
