Fujii Masao wrote: > Hi, > > On Wed, Jul 15, 2009 at 8:15 PM, Robert Haas<robertmh...@gmail.com> wrote: >> So I think you should update ASAP in this case. > > I updated the patch as described in > http://archives.postgresql.org/pgsql-hackers/2009-07/msg00865.php > > All the other parts are still the same. > >> As soon as we get >> some reviewers freed up from the initial reviewing round, I will >> assign one or more reviewers to the main Sync Rep patch. > > Thanks!
I don't think there's much point assigning more reviewers to Synch Rep at this point. I believe we have consensus on four major changes: 1. Change the way synchronization is done when standby connects to primary. After authentication, standby should send a message to primary, stating the <begin> point (where <begin> is an XLogRecPtr, not a WAL segment name). Primary starts streaming WAL starting from that point, and keeps streaming forever. pg_read_xlogfile() needs to be removed. 2. The primary should have no business reading back from the archive. The standby can read from the archive, as it can today. 3. Need to support multiple WALSenders. While multiple slave support isn't 1st priority right now, it's not acceptable that a new WALSender can't connect while one is active already. That can cause trouble in case of network problems etc. 4. It is not acceptable that normal backends have to wait for walsender to send data. That means that connecting a standby behind a slow connection to the primary can grind the primary to a halt. walsender needs to be able to read data from disk, not just from shared memory. (I raised this back in December http://archives.postgresql.org/message-id/495106fa.1050...@enterprisedb.com) Those 4 things are big enough changes that I don't think there's much left to review that won't be affected by those changes. As a hint, I think you'll find it a lot easier if you implement only asynchronous replication at first. That reduces the amount of inter-process communication a lot. You can then add synchronous capability in a later commitfest. I would also suggest that for point 4, you implement WAL sender so that it *only* reads from disk at first, and only add the capability send from wal_buffers later on, and only if performance testing shows that it's needed. I'll move this to "returned with feedback" section, but if you get those things done quickly we can still give it another round of review in this commitfest. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
