Re: [HACKERS] pg_stat_replication vs StandbyReplyMessage
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
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
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
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
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
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
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
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
Re: [HACKERS] pg_stat_replication vs StandbyReplyMessage
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
