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: (view raw or whole 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.
>> 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.



In response to


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

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