On Fri, Jul 3, 2009 at 12:32 AM, Fujii Masao<masao.fujii@gmail.com> wrote:
> Hi,
>
> On Fri, Jul 3, 2009 at 11:02 AM, Robert Haas<robertmhaas@gmail.com> wrote:
>> On Tue, Jun 16, 2009 at 2:13 AM, Fujii Masao<masao.fujii@gmail.com> wrote:
>>> The attached latest patch provides this capability. You can easily set up the
>>> synch rep according to the following procedure.
>>> http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects#How_to_set_up_Synch_Rep
>>
>> This patch no longer applies cleanly. Can you rebase and resubmit it
>> for the upcoming CommitFest? It might also be good to go through and
>> clean up the various places where you have trailing whitespace and/or
>> spaces preceding tabs.
>
> Sure. I'll resubmit the patch after fixing some bugs and finishing
> the documents.
>
>> Given that this is a substantial patch, I have a couple of questions
>> about strategy. First, I am wondering whether this patch should be
>> reviewed (and committed) as a whole, or whether there are distinct
>> chunks of it that should be reviewed and committed separately -
>> particularly the signal handling piece, which AIUI is independently
>> useful. I note that it seems to be included in the tarball as a
>> separate patch file, which is very useful.
>
> I think that the latter strategy makes more sense. At least, the signal
> handling piece and non-blocking pqcomm (communication between
> a frontend and a backend) can be reviewed independently of synch rep
> itself.
My preference for ease of CommitFest management would be one thread on
-hackers for each chunk that can be separately reviewed and committed.So if there are three severable chunks here, send
apatch for each
one with a descriptive subject line, and mention the dependencies in
the body of the email ("before applying this patch, you must first
apply blah blah <link to archives>"). That way, we can keep the
discussion of each topic separate, have separate entries on the
CommitFest page with subjects that match the email thread, etc.
Thanks,
...Robert
