On Tue, Aug 16, 2011 at 16:00, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Tue, Aug 16, 2011 at 2:25 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Aug 16, 2011 at 8:54 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>>> On Mon, Aug 15, 2011 at 13:50, Robert Haas <robertmhaas@gmail.com> wrote:
>>>>> On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>>>>> The pg_stat_replication view exposes all the fields in
>>>>>> StandbyReplyMessage *except* for the timestamp when the message was
>>>>>> generated. On an active system this is not all that interesting, but
>>>>>> on a mostly idle system that allows the monitoring to react faster
>>>>>> than the timeout that actually kicks the other end off - and could be
>>>>>> useful in manual debugging scenarios. Any particular reason why this
>>>>>> was not exposed as it's own column?
>>>>>
>>>>> I wondered the same thing. Sounds like a good idea.
>>>>
>>>> I can go do that. Care to argue^Wbikeshed for a specific name?
>>>
>>> reply_timestamp
>>
>> Works for me.
>
>> I'd suggest that we rename it that way in
>> StandbyReplyMessage, so that the name in the struct and the name in
>> the system view match.
>
> -1
>
> The field is named same as equivalent field in other messages.
>
> The field on the view is a summary of all previous messages, which is
> a different thing. Perhaps we should call it last_reply_timestamp to
> make that clearer, though long titles are annoying.
We don't say last_replay_location either, we just say replay_location.
Adding the last_ part is just annoying.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/