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

Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date: 2011-03-18 05:45:44
Message-ID: AANLkTimAcuYBQZpmAyrHzzSFKVNQJKTvPpC-LRNx8WYL@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Fri, Mar 18, 2011 at 2:52 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Mar 10, 2011 at 3:04 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> -                       /* Let the master know that we received some data. */
>>> -                       XLogWalRcvSendReply();
>>> -                       XLogWalRcvSendHSFeedback();
>>>
>>> This change completely eliminates the difference between write_location
>>> and flush_location in pg_stat_replication. If this change is reasoable, we
>>> should get rid of write_location from pg_stat_replication since it's useless.
>>> If not, this change should be reverted. I'm not sure whether monitoring
>>> the difference between write and flush locations is useful. But I guess that
>>> someone thought so and that code was added.
>>
>> I could go either way on this but clearly we need to do one or the other.
>
> I'm not really sure why this was part of the synchronous replication
> patch, but after mulling it over I think it's probably right to rip
> out write_location completely.  There shouldn't ordinarily be much of
> a gap between write location and flush location, so it's probably not
> worth the extra network overhead to keep track of it.  We might need
> to re-add some form of this in the future if we have a version of
> synchronous replication that only waits for confirmation of receipt
> rather than for confirmation of flush, but we don't have that in 9.1,
> so why bother?
>
> Barring objections, I'll go do that.

I agree to get rid of write_location.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2011-03-18 06:25:06
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Fujii MasaoDate: 2011-03-18 05:13:13
Subject: Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,

pgsql-committers by date

Next:From: Fujii MasaoDate: 2011-03-18 06:25:06
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Fujii MasaoDate: 2011-03-18 05:13:13
Subject: Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,

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