Hello Zoltán, Fujii and list,
Kevin asked me to do a preliminary review on both synchronous
replication patches. Relevant posts on -hackers are:
(A) http://archives.postgresql.org/pgsql-hackers/2010-04/msg01516.php
(B)
http://archives.postgresql.org/message-id/AANLkTilgyL3Y1jkDVHX02433COq7JLmqicsqmOsbuyA1@mail.gmail.com
(1) http://archives.postgresql.org/pgsql-hackers/2010-05/msg00746.php
(2) http://archives.postgresql.org/pgsql-hackers/2010-05/msg01047.php
(3)
http://wiki.postgresql.org/wiki/Streaming_Replication#Synchronization_capability
The first patch (A) was posted by Zoltán Böszörményi three months ago,
with comments on -hackers in thread (1). The second patch by Fujii Masao
a few days ago (B).
Since both patches overlap in functionality, applying one in core means
not applying the other. Initially I set out to do a complete review of
both patches and let the difficult choice of preferring one over the
other to fellow reviewers. However, for the following reasons I believe
that patch (A) should probably be withdrawn and the review effort
continued on (B).
* patch (A) was designed and programmed without prior community
involvement. This in itself doesn't make it a bad patch nor a bad way of
contributing source code, however thread (1) shows that some issues were
raised and more ideas existed.
* one of the leafs of thread (A) was (4) where Zoltán Böszörményi hints
there might be a new version of the patch (replacing XIDs with LSNs).
However to date no new version was posted. Also this in itself is not
ground for rejection, but together with the existence of patch (B) gives
rise to the idea that work on (A) might have halted.
* the work on patch (B) started actually with the post (1) where Fujii
Masao indicates he is going to write a patch too, and proposes to work
together with Zoltán Böszörményi on the design.
* patch (B) encompasses functionality of (A) and more, it also addresses
some, if not all ideas on the design that were raised in the comments on
patch (A)
Adding this up I have the impression that patch (A) will not get a newer
version, based on the fact that a newer patch (B) exists which has more
functionality and is partly based on community feedback on patch (A),
where patch (A) itself is not. Therefore I think that the focus and
review time during this commitfest should be on patch (B), unless Zoltán
Böszörményi disagrees and supplies a new version of this patch.
Depending on a reaction of Zoltán Böszörményi I think patch (A) should
be set to either "Returned With Feedback", if a new version is in the
making, or "Rejected" if not.
regards,
Yeb Havinga
