Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Flatly)
  • No Skin
Collapse
Brand Logo

NetXMS Forum

  1. Home
  2. Development
  3. PostgreSQL subagent

PostgreSQL subagent

Scheduled Pinned Locked Moved Development
14 Posts 2 Posters 40.5k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • V
    V
    Victor Kirhenshtein
    wrote on last edited by
    #5

    Hi,

    current subagent version reports the following SQL error on each poll:

    SELECT CASE WHEN pg_is_in_recovery() THEN 'YES' ELSE 'NO' END AS in_recovery,  CASE WHEN count(*) > 0 THEN 'YES' ELSE 'NO' END AS is_receiver FROM pg_catalog.pg_stat_wal_receiver
    42P01 ERROR:  relation "pg_catalog.pg_stat_wal_receiver" does not exist
    

    Is it possible to somehow detect if this view is present and remove it from polling if not?

    Best regards,
    Victor

    1 Reply Last reply
    0
    • P
      P
      pvo
      wrote on last edited by
      #6

      It is strange. I've tested it with versions 12 and 9.6 both without WAL replication and I dint have this message.

      Which version did you test it with? If >= 10 do you have the pg_monitor role assigned?

      1 Reply Last reply
      0
      • V
        V
        Victor Kirhenshtein
        wrote on last edited by
        #7

        It is 9.5.13. I will retest it on 9.6. I'm not sure about support for 9.5 - formally it is supported until 2021, but I don't know how widely it is used.

        Best regards,
        Victor

        1 Reply Last reply
        0
        • P
          P
          pvo
          wrote on last edited by
          #8

          The easiest way to solve it is to limit the remaining two REPLICATION SQL queries by minimal version MAKE_PGSQL_VERSION(9, 6, 0) ;).

          1 Reply Last reply
          0
          • V
            V
            Victor Kirhenshtein
            wrote on last edited by
            #9

            Added it. Now I have a question regarding these lines:

            "SELECT count(*) stanby FROM pg_catalog.pg_stat_replication

             { _T("PostgreSQL.Replication.Stanby(*)"), H_GlobalParameter, _T("REPLICATION/stanby"), DCI_DT_INT64, _T("PostgreSQL/Replication: WAL senders") },

            shouldn't it be "standby"? Or even "PostgreSQL.Replication.WALSenders"?

            I don't know meaning of this parameter, question is based purely on name and description difference 🙂

            Best regards,
            Victor

            1 Reply Last reply
            0
            • P
              P
              pvo
              wrote on last edited by
              #10

              It is number of WAL senders which 1:1 corresponds with the number of Standby servers receiving WAL form this master server.
              I don't know which name or description is better, but you are right that the parameter name and its description should be unified. This means either rename the parameter to "PostgreSQL.Replication.WALSenders" as you suggest or change the description of the parameter in the documentation to "Number of Standby servers".

              1 Reply Last reply
              0
              • V
                V
                Victor Kirhenshtein
                wrote on last edited by
                #11

                Should it be "WAL receivers" or "WAL sending targets" then - as those servers receive data from current server, not send data to it?

                1 Reply Last reply
                0
                • P
                  P
                  pvo
                  wrote on last edited by
                  #12

                  The exact description of the pg_stat_replication table is: "One row per WAL sender process, showing statistics about replication to that sender's connected standby server."

                  The query counts the number of the rows in this table therefore it is number of senders (sender processes) on the monitored master server which corresponds with number of Standby servers on the other side receiving the data.

                  1 Reply Last reply
                  0
                  • V
                    V
                    Victor Kirhenshtein
                    wrote on last edited by
                    #13

                    Now it makes sense 🙂 I think PostgreSQL.Replication.WALSenders will be the best name then.

                    Best regards,
                    Victor

                    1 Reply Last reply
                    0
                    • P
                      P
                      pvo
                      wrote on last edited by
                      #14

                      OK.

                      Technically is it what is monitored. From the human perspective is more logical to know how many Stanby servers are receiving the WALs therefore I've chosen the name PostgreSQL.Replication.Stanby. But it is name only the number is always the same.

                      1 Reply Last reply
                      0

                      Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                      Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                      With your input, this post could be even better 💗

                      Register Login
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      Powered by NodeBB Contributors
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups