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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(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-17 17:52:56
Message-ID: AANLkTikP1TZVHp68nqk6p7aMJ4S0tUTxdEnbDdguzL_8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2011-03-17 17:55:20 Re: [COMMITTERS] pgsql: Fix various possible problems with synchronous replication.
Previous Message Robert Haas 2011-03-17 17:46:37 Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-03-17 17:55:20 Re: [COMMITTERS] pgsql: Fix various possible problems with synchronous replication.
Previous Message Robert Haas 2011-03-17 17:46:37 Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.