Re: [HACKERS] pg_stat_replication vs StandbyReplyMessage

2012-08-25 Thread Bruce Momjian
On Thu, Aug 23, 2012 at 12:40:33PM +0200, Magnus Hagander wrote:
 On Wed, Aug 15, 2012 at 5:39 PM, Bruce Momjian br...@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  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_stat_replication vs StandbyReplyMessage

2012-08-23 Thread Magnus Hagander
On Wed, Aug 15, 2012 at 5:39 PM, Bruce Momjian br...@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/


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_stat_replication vs StandbyReplyMessage

2012-08-15 Thread Bruce Momjian
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  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_stat_replication vs StandbyReplyMessage

2011-08-16 Thread Magnus Hagander
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?

-- 
 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


Re: [HACKERS] pg_stat_replication vs StandbyReplyMessage

2011-08-16 Thread Simon Riggs
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

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_stat_replication vs StandbyReplyMessage

2011-08-16 Thread Robert Haas
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.

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_stat_replication vs StandbyReplyMessage

2011-08-16 Thread Simon Riggs
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.

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_stat_replication vs StandbyReplyMessage

2011-08-16 Thread Magnus Hagander
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


[HACKERS] pg_stat_replication vs StandbyReplyMessage

2011-08-15 Thread Magnus Hagander
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/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_stat_replication vs StandbyReplyMessage

2011-08-15 Thread Robert Haas
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.

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers