Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)

On Fri, Mar 25, 2011 at 5:03 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Fri, Mar 25, 2011 at 6:11 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Mar 24, 2011 at 2:28 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> The protocol supports sending two values, so two are displayed.
>>>
>>> If you wish to remove one from the display then that only makes sense
>>> if you also prevent the protocol from supporting two values.
>>>
>>> There is no benefit in doing that, so why do it? We are going to put
>>> that back in 9.2 if you remove it now. Why not leave it, so we don't
>>> need to rewrite all the monitoring tools that will use this view?
>
> What are you planning to use write_location for? BTW, I'm thinking to
> add recv_location (not write_location) in 9.2 to support another sync rep
> mode which makes transactions wait until the standby has received
> (not fsync'd) the WAL. You're planning the same?
>
>> If we're going to put it back in 9.2, then we shouldn't remove it now.
>>  We should just make it work.  It's a three line patch.  If 9.2 is
>> going to meaningfully distinguish between write location and flush
>> location, then we may as well do the same thing in 9.1.  Then we'll be
>> ahead of the game: not only will the view have the same columns in
>> both releases, but they'll actually have the same semantics in both
>> releases.
>
> +1

I think we have adequate consensus on this topic, so committed.

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