Thread: 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 HaganderMe: 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. +
Hello hackers, Still need to solve this topic? https://www.postgresql.org/message-id/flat/CABUevEwA%3DAFWXr-7cCpZ9MDdxHL2wFGsxFiB6uyFDTOhRudGrA%40mail.gmail.com I saw this topic in todo list, so I implemented simple patch. https://www.postgresql.org/message-id/flat/1657809367.407321.1533027417725.JavaMail.jboss%40ep2ml404 If it was not necessary, please let me know. Feedback and suggestion will be very welcome. Thanks! Best regards, Myungkyu, Lim ---------------------------------------------------------------------------------- From: Bruce Momjian <bruce(at)momjian(dot)us> To: Magnus Hagander <magnus(at)hagander(dot)net> Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> Subject: Re: pg_stat_replication vs StandbyReplyMessage Date: 2012-08-25 20:46:51 Message-ID: 20120825204651.GC10814@momjian.us Views: Raw Message | Whole Thread | Download mbox Lists: pgsql-hackers 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 --
MyungKyu LIM wrote: > I saw this topic in todo list, > > so I implemented simple patch. > > https://www.postgresql.org/message-id/flat/1657809367.407321.1533027417725.JavaMail.jboss%40ep2ml404 For the archives' sake, please always reply on the original thread. Yours, Laurenz Albe
On Thu, Oct 25, 2018 at 08:13:53AM +0200, Laurenz Albe wrote: > MyungKyu LIM wrote: >> I saw this topic in todo list, >> >> so I implemented simple patch. >> >> https://www.postgresql.org/message-id/flat/1657809367.407321.1533027417725.JavaMail.jboss%40ep2ml404 > > For the archives' sake, please always reply on the original thread. And if you could add some documentation into the patch, and register it to the commit fest if you would like to get it reviewed, that would be nice. Here are some general guidelines on the matter: https://wiki.postgresql.org/wiki/Submitting_a_Patch -- Michael