On Thu, 2010-12-30 at 18:47 -0600, Jim Nasby wrote: > On Dec 30, 2010, at 3:27 PM, Robert Haas 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 > > I think that comment is valid for the entire set of docs, actually. The > document goes out of its way to avoid simple phrases like "replicated", but > doesn't spell out exactly what is happening, ie: > > "Synchronous replication offers the ability to guarantee that all changes > made by a transaction have been transferred to at least one remote > standby server. This is an extension to the standard level of durability > offered by a transaction commit. This is referred to as semi-synchronous > replication." > > Reading that, I'm left with the sense that this isn't a simple matter of "Oh, > the data has been replicated to the slave before commit returns", but nothing > does a good job of clearly explaining what the distinction is and what it > means. This section: > > "The guarantee we offer is that the application will not receive > explicit acknowledgement of the successful commit of a transaction until > the WAL data is known to be safely received by the standby. Hence this > mechanism is technically "semi synchronous" rather than "fully > synchronous" replication." > > does provide some enlightenment, but it's at the end of the section. I think > it would be best if there was a section right at the beginning that talked > about the data quality issue of sync replication and how we're avoiding it > with our semi-sync solution.
I'm happy to change the docs. It's the first draft... If that's the only problem you've got, then I'm feeling good. Any problems with the user interface itself? -- 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