Re: Hot standby and synchronous replication status - Mailing list pgsql-hackers

On Mon, Aug 10, 2009 at 9:51 PM, Bruce Momjian<bruce@momjian.us> wrote:
> What is the status of hot standby and synchronous replication?  Is there
> a design specification?  Who are the lead developers?  Who is assisting?
> What open item do we have for each feature?  Where is the most recent
> patch?  Can we incrementally start applying patches for these features?
>
> Would someone create a wiki for each of these features and update it so
> we can be sure of their status as we move into September/October?  I
> would like to have some traction on these in the next few months rather
> than waiting for the later commitfests.

For what it's worth, there are already some materials on the wiki
about these projects:

http://wiki.postgresql.org/wiki/Hot_Standby
http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects

To get a real project status, I think we need input from Heikki, who
is the person who will likely be committing whatever of this work gets
into 8.5, and who is also the committer who has been following these
patches most closely, at least AIUI.  Tom may also have some thoughts.

But just to kick off the discussion, here is Heikki's review of Synch
Rep on 7/15:

http://archives.postgresql.org/pgsql-hackers/2009-07/msg00913.php

I think the key phrases in this review are "I believe we have
consensus on four major changes" and "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."
I think this points to a need to try to reduce the scope of this patch
to something more manageable.  Heikki also points out that major
change #4 was raised back in Decemeber, and I actually think #1 and #3
were as well.

We should probably have a separate discussion about what the least
committable unit would be for this patch.  I wonder if it might be
sufficient to provide a facility for streaming WAL, plus a standalone
tool for receving it and storing it to a file.  This might be designed
as an improvement on our existing concept of an archive; the advantage
would be that you could have all but perhaps the last few seconds of
WAL if the primary kicked the bucket, rather than being behind by up
to checkpoint_timeout.  Allowing the WAL to be received directly by
PostgreSQL could be a future enhancement.

(But take all of this with a grain of salt, because as I say I haven't
read the patch and am not familiar with this part of the code either.)

I think Hot Standby is in somewhat better shape.  Having read the
patch, I can say that it needs a pretty substantial amount of cleanup
work: the code is messy.  But Heikki was talking fairly seriously
about committing this for 8.4, and everyone seems to agree that the
architecture is approximately right.  It's not clear to me how much
more refactoring is needed or whether there are remaining bugs, but at
least it looks to me like a reviewable version of the patch could be
produced with a fairly modest amount of work.

Heikki stated (in response to a question from me) that he was not
aware of anything that could be severed from Hot Standby and committed
independently, and nothing jumped out at me when I read the patch
either.  But if the whole patch can be made committable in time then
it's less critical.

Having offered those rather bold opinions, I'm going to repeat the
thought I started out with: we need to hear from Heikki.

...Robert