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@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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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?
--
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@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
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
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/
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@momjian.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@momjian.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@momjian.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +