On 19 February 2011 00:06, Simon Riggs <si...@2ndquadrant.com> wrote: > > Well, good news all round. > > v17 implements what I believe to be the final set of features for sync > rep. This one I'm actually fairly happy with. It can be enjoyed best at > DEBUG3. > > The patch is very lite touch on a few areas of code, plus a chunk of > specific code, all on master-side. Pretty straight really. I'm sure > problems will be found, its not long since I completed this; thanks to > Daniel Farina for your help with patch assembly. > > Which is just as well, because the other news is that I'm off on holiday > for a few days, which is most inconvenient. I won't be committing this > for at least a week and absent from the list. OTOH, I think its ready > for a final review and commit, so I'm OK if you commit or OK if you > leave it for me. > > That's not the end of it. I can see a few things we could/should do in > this release, but this includes all the must-do things. Docs could do > with a little love also. So I expect work for me when I return. > > > > > Config Summary > ============== > > Most parameters are set on the primary. Set > > primary: synchronous_standby_names = 'node1, node2, node3' > > which means that whichever of those standbys connect first will > become the main synchronous standby. Servers arriving later will > be potential standbys (standby standbys doesn't sound right...). > synchronous_standby_names can change at reload. > > Currently, the standby_name is the application_name parameter > set in the primary_conninfo. > > When we set this for a client, or in postgresql.conf > > primary: synchronous_replication = on > > then we will wait at commit until the synchronous standby has > reached the WAL location of our commit point. > > If the current synchronous standby dies then one of the other standbys > will take over. (I think it would be a great idea to make the > list a priority order, but I haven't had time to code that). > > If none of the standbys are available, then we don't wait at all > if allow_standalone_primary is set. > allow_standalone_primary can change at reload. > > Whatever happens, if you set sync_replication_timeout_client > then backends will give up waiting if some WALsender doesn't > wake them quickly enough. > > You can generally leave these parameters at their default settings > > primary: sync_replication_timeout_client = 120s > primary: allow_standalone_primary = on > standby: wal_receiver_status_interval = 10s
I see the updated patch I provided last time to fix various errata and spacing issues got lost in the last round of conversations. Maybe it's safer to provide a patch for the patch. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers