Skip site navigation (1) Skip section navigation (2)

Re: Synch Rep: direct transfer of WAL file from the primary to the standby

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Synch Rep: direct transfer of WAL file from the primary to the standby
Date: 2009-07-03 05:01:40
Message-ID: 603c8f070907022201v63f2cbc2q489e35989d32beba@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Jul 3, 2009 at 12:32 AM, Fujii Masao<masao(dot)fujii(at)gmail(dot)com> wrote:
> Hi,
>
> On Fri, Jul 3, 2009 at 11:02 AM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Jun 16, 2009 at 2:13 AM, Fujii Masao<masao(dot)fujii(at)gmail(dot)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 a patch 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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-07-03 05:07:46
Subject: Re: [PATCH] SE-PostgreSQL Updates rev.2096
Previous:From: Robert HaasDate: 2009-07-03 04:57:35
Subject: commitfest.postgresql.org

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group