pg_stat_replication vs StandbyReplyMessage

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?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander <magnus(at)hagander(dot)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.

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

On Mon, Aug 15, 2011 at 13:50, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander <magnus(at)hagander(dot)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?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Mon, Aug 15, 2011 at 13:50, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander <magnus(at)hagander(dot)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

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On Tue, Aug 16, 2011 at 8:54 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Mon, Aug 15, 2011 at 13:50, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander <magnus(at)hagander(dot)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.

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

On Tue, Aug 16, 2011 at 2:25 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Aug 16, 2011 at 8:54 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> On Mon, Aug 15, 2011 at 13:50, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander <magnus(at)hagander(dot)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.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On Tue, Aug 16, 2011 at 16:00, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Tue, Aug 16, 2011 at 2:25 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Aug 16, 2011 at 8:54 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>> On Mon, Aug 15, 2011 at 13:50, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>>> On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander <magnus(at)hagander(dot)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/

On Mon, Aug 15, 2011 at 01:03:35PM +0200, Magnus Hagander 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?

Did this ever get done? I don't think so, though everyone wanted it.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Wed, Aug 15, 2012 at 5:39 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Mon, Aug 15, 2011 at 01:03:35PM +0200, Magnus Hagander 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?
>
> Did this ever get done? I don't think so, though everyone wanted it.

Nope, it wasn't done. Should probably do that for 9.3 (since adding a
field to pg_stat_replication will cause initdb, so we can't really do
it for 9.2 unless it was really critical - and it's not).

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Thu, Aug 23, 2012 at 12:40:33PM +0200, Magnus Hagander wrote:
> On Wed, Aug 15, 2012 at 5:39 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > On Mon, Aug 15, 2011 at 01:03:35PM +0200, Magnus Hagander 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?
> >
> > Did this ever get done? I don't think so, though everyone wanted it.
>
> Nope, it wasn't done. Should probably do that for 9.3 (since adding a
> field to pg_stat_replication will cause initdb, so we can't really do
> it for 9.2 unless it was really critical - and it's not).

OK, TODO added:

Add entry creation timestamp column to pg_stat_replication

http://archives.postgresql.org/pgsql-hackers/2011-08/msg00694.php

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +