Re: Synch Rep for CommitFest 2009-07

Fujii Masao wrote:
> Hi,
>
> On Wed, Jul 15, 2009 at 8:15 PM, Robert Haas<robertmhaas(at)gmail(dot)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.1050605@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