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
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
