On Tue, Aug 16, 2011 at 16:00, Simon Riggs <si...@2ndquadrant.com> wrote: > On Tue, Aug 16, 2011 at 2:25 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Tue, Aug 16, 2011 at 8:54 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander <mag...@hagander.net> >>> wrote: >>>> On Mon, Aug 15, 2011 at 13:50, Robert Haas <robertmh...@gmail.com> wrote: >>>>> On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander <mag...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
