4 added 5 characters in body
source | link

Update Monitor is a little utility from EnterpriseDB that notifies of needed updates. It is not very much documented and doesn't have any obvious way to configure itself. It can be considered non essential, in the sense that the database will perfectly work without it, and you will most probably not miss its functionality.

It's function is explained in the EnterpriseDB website. EDB has also have a Support Page, with contact possibilities that might provide a solution to the malfunction of Update Monitor.

Being a non-essential utility (I've lived without it for very long), if it is giving some annoying popups, I'd consider that the cost versus profit ratio is not favourable, and I'd recommend to, simply, uninstall it. The usual unistall process of any Windows 10 program should be sufficient.

In order to be "up to date" with regard to everything related to PostgreSQL development, it's good to register to the "pgsql-announce@postgresql.org" mailing list from postgresql.org. They'll send one to three emails per week, neat and simple. Any critical update is always announced ASAP.

Update Monitor is a little utility from EnterpriseDB that notifies of needed updates. It is not very much documented and doesn't have any obvious way to configure itself. It can be considered non essential, in the sense that the database will perfectly work without it, and you will most probably not miss its functionality.

It's function is explained in the EnterpriseDB website. EDB has also have a Support Page, with contact possibilities that might provide a solution to the malfunction of Update Monitor.

Being a non-essential utility (I've lived without it for very long), if it is giving some annoying popups, I'd consider that the cost versus profit ratio is not favourable, and I'd recommend to, simply, uninstall it. The usual unistall process of any Windows 10 program should be sufficient.

In order to be "up to date" with regard to everything related to PostgreSQL development, it's good to register to the "pgsql-announce@postgresql.org" mailing list from postgresql.org. They'll one to three emails per week, neat and simple. Any critical update is always announced ASAP.

Update Monitor is a little utility from EnterpriseDB that notifies of needed updates. It is not very much documented and doesn't have any obvious way to configure itself. It can be considered non essential, in the sense that the database will perfectly work without it, and you will most probably not miss its functionality.

It's function is explained in the EnterpriseDB website. EDB has also have a Support Page, with contact possibilities that might provide a solution to the malfunction of Update Monitor.

Being a non-essential utility (I've lived without it for very long), if it is giving some annoying popups, I'd consider that the cost versus profit ratio is not favourable, and I'd recommend to, simply, uninstall it. The usual unistall process of any Windows 10 program should be sufficient.

In order to be "up to date" with regard to everything related to PostgreSQL development, it's good to register to the "pgsql-announce@postgresql.org" mailing list from postgresql.org. They'll send one to three emails per week, neat and simple. Any critical update is always announced ASAP.

    Bounty Ended with 100 reputation awarded by Dr.YSG
3 deleted 2192 characters in body
source | link

Based on the comment

Pgadmin keeps throwing up a connection timeout every 10 minutes or so. I want that to stop. I don't have access to the connection string pgadmin uses.

I would thinkUpdate Monitor is a little utility from EnterpriseDB that the problem might be relatednotifies of needed updates. It is not very much documented and doesn't have any obvious way to aconfigure itself. It can be considered routernon essential (or, in some casesthe sense that the database will perfectly work without it, a stateful firewall) between your pgAdmin client and the PostgreSQL serveryou will most probably not miss its functionality.

ThisIt's function is quite common when you are at home (orexplained in the office) and your router is performing NAT (Network Address Translation)EnterpriseDB website. After some idle time the connection is closedEDB has also have a by the router. It is not something done by neither pgAdmin nor PostgreSQLSupport Page, this is somethingwith contact possibilities that depends on the settings on the router,

If this is the case, you have three options:

  1. Change the connection_timeout setting in your router, if that is feasible and you have the proper documentation. Here is an example for Cisco routers.

  2. Make the router believe the connection is never idle for long enough. To do that: change one server parameter, called tcp_keep_alives:

According to the PostgreSQL documentation on Connections:

tcp_keepalives_idle (integer)

Specifies the number of seconds of inactivity after which TCP should send a keepalive message to the client. A value of 0 uses the system default. This parameter is supported only on systems that support the TCP_KEEPIDLE or TCP_KEEPALIVE symbols, and on Windows; on other systems, it must be zero. In sessions connected via a Unix-domain socket, this parameter is ignored and always reads as zero.

The keepalive message shouldmight avoid the NAT connectionprovide a solution to be droppedthe malfunction of Update Monitor.

Keep in mind the remark in the documentation:Being a non-essential utility

This parameter is supported only on systems that support the TCP_KEEPIDLE or TCP_KEEPALIVE symbols, and on Windows

I really don't know which systems "support TCP_KEEPIDLE or TCP_KEEPALIVE symbols"(I've lived without it for very long), but I guess that Linux and Macif it is giving some shouldannoying popups support them, and so does Windows.

If your system disconnects every 10 minutesI'd consider that the cost versus profit ratio is not favourable, it should be prudent to have this settingand I'd recommend to something around 9 * 60 = 540 seconds, or lesssimply, uninstall it.

This setting The usual unistall process of any Windows 10 program should be in the postgresql.conf on your serversufficient. You can also test before making the change in the server, by either using the commands:

SET tcp_keepalives_idle = 480 ;

which would alter the setting for your current connectionIn order to be "up to date" with regard to everything related to PostgreSQL development, or

ALTER role (the-one-you-use) SET tcp_keepalives_idle = 480 ;

which would alter the setting only for this role.

  1. Change the keep_alives on the client. You don't need to change any connection_timeout (that parameter is "how long to wait for a connection before deciding that the other side is not responding). Follow the instructions of the accepted answer of Any way to keep connection alive in pgAdmin without setting it on the server?. It's perfectly explained.

Reference: Thisit's good to video talks about How to Keep Your SSH Sessions Aliveregister to the "pgsql-announce@postgresql.org" mailing list from postgresql.org. Although this is not exactly the same scenarioThey'll one to three emails per week, itneat and simple. Any critical update is equivalent (substitute SSH by pgAdmin)always announced ASAP.

Based on the comment

Pgadmin keeps throwing up a connection timeout every 10 minutes or so. I want that to stop. I don't have access to the connection string pgadmin uses.

I would think that the problem might be related to a router (or, in some cases, a stateful firewall) between your pgAdmin client and the PostgreSQL server.

This is quite common when you are at home (or in the office) and your router is performing NAT (Network Address Translation). After some idle time the connection is closed by the router. It is not something done by neither pgAdmin nor PostgreSQL, this is something that depends on the settings on the router,

If this is the case, you have three options:

  1. Change the connection_timeout setting in your router, if that is feasible and you have the proper documentation. Here is an example for Cisco routers.

  2. Make the router believe the connection is never idle for long enough. To do that: change one server parameter, called tcp_keep_alives:

According to the PostgreSQL documentation on Connections:

tcp_keepalives_idle (integer)

Specifies the number of seconds of inactivity after which TCP should send a keepalive message to the client. A value of 0 uses the system default. This parameter is supported only on systems that support the TCP_KEEPIDLE or TCP_KEEPALIVE symbols, and on Windows; on other systems, it must be zero. In sessions connected via a Unix-domain socket, this parameter is ignored and always reads as zero.

The keepalive message should avoid the NAT connection to be dropped.

Keep in mind the remark in the documentation:

This parameter is supported only on systems that support the TCP_KEEPIDLE or TCP_KEEPALIVE symbols, and on Windows

I really don't know which systems "support TCP_KEEPIDLE or TCP_KEEPALIVE symbols", but I guess that Linux and Mac should support them, and so does Windows.

If your system disconnects every 10 minutes, it should be prudent to have this setting to something around 9 * 60 = 540 seconds, or less.

This setting should be in the postgresql.conf on your server. You can also test before making the change in the server, by either using the commands:

SET tcp_keepalives_idle = 480 ;

which would alter the setting for your current connection, or

ALTER role (the-one-you-use) SET tcp_keepalives_idle = 480 ;

which would alter the setting only for this role.

  1. Change the keep_alives on the client. You don't need to change any connection_timeout (that parameter is "how long to wait for a connection before deciding that the other side is not responding). Follow the instructions of the accepted answer of Any way to keep connection alive in pgAdmin without setting it on the server?. It's perfectly explained.

Reference: This video talks about How to Keep Your SSH Sessions Alive. Although this is not exactly the same scenario, it is equivalent (substitute SSH by pgAdmin).

Update Monitor is a little utility from EnterpriseDB that notifies of needed updates. It is not very much documented and doesn't have any obvious way to configure itself. It can be considered non essential, in the sense that the database will perfectly work without it, and you will most probably not miss its functionality.

It's function is explained in the EnterpriseDB website. EDB has also have a Support Page, with contact possibilities that might provide a solution to the malfunction of Update Monitor.

Being a non-essential utility (I've lived without it for very long), if it is giving some annoying popups, I'd consider that the cost versus profit ratio is not favourable, and I'd recommend to, simply, uninstall it. The usual unistall process of any Windows 10 program should be sufficient.

In order to be "up to date" with regard to everything related to PostgreSQL development, it's good to register to the "pgsql-announce@postgresql.org" mailing list from postgresql.org. They'll one to three emails per week, neat and simple. Any critical update is always announced ASAP.

2 added 787 characters in body
source | link

Based on the comment "Pgadmin keeps throwing up a connection timeout every 10 minutes or so. I want that to stop. I don't have access to the connection string pgadmin uses."

Pgadmin keeps throwing up a connection timeout every 10 minutes or so. I want that to stop. I don't have access to the connection string pgadmin uses.

I would think that the problem might be related to a router (or, in some cases, a firewallstateful firewall) betweenbetween your pgAdmin client and the PostgreSQL server. 

This is quite common when you are at home (or in the office) and your router is doingperforming NAT (Network Address TranslationNetwork Address Translation). After some idle time (that depends on the settings on the router) the connection is closed by the router. It is not something done by neither pgAdmin nor PostgreSQL, this is something that depends on the settings on the router,

If this is the case, you have twothree options:

  1. Change the settingsconnection_timeout setting in your routerrouter, if that is feasible and you have the proper documentation. Here is an example for Cisco routers.

  2. ChangeMake the router believe the connection is never idle for long enough. To do that: change one server parameter, called tcp_keep_alives:

According to the PostgreSQL documentation on Connections:

tcp_keepalives_idle (integer)

Specifies the number of seconds of inactivity after which TCP should send a keepalive message to the client. A value of 0 uses the system default. This parameter is supported only on systems that support the TCP_KEEPIDLE or TCP_KEEPALIVE symbols, and on Windows; on other systems, it must be zero. In sessions connected via a Unix-domain socket, this parameter is ignored and always reads as zero.

The keepalive message should avoid the NAT connection to be dropped.

Keep in mind the remark in the documentation:

This parameter is supported only on systems that support the TCP_KEEPIDLE or TCP_KEEPALIVE symbols, and on Windows

I really don't know which systems "support TCP_KEEPIDLE or TCP_KEEPALIVE symbols", but I guess that Linux and Mac should support them, and so does Windows.

If your system disconnects every 10 minutes, it should be prudent to have this setting to something around 9 * 60 = 540 seconds, or less.

This setting should be in the postgresql.conf on your server. You can also test before making the change in the server, by either using the commands:

SET tcp_keepalives_idle = 480 ;

which would alter the setting for your current connection, or

ALTER role (the-one-you-use) SET tcp_keepalives_idle = 480 ;

which would alter the setting only for this role.

  1. Change the keep_alives on the client. You don't need to change any connection_timeout (that parameter is "how long to wait for a connection before deciding that the other side is not responding). Follow the instructions of the accepted answer of Any way to keep connection alive in pgAdmin without setting it on the server?. It's perfectly explained.

Reference: This video talks about How to Keep Your SSH Sessions Alive. Although this is not exactly the same scenario, it is equivalent (substitute SSH by pgAdmin).

Based on the comment "Pgadmin keeps throwing up a connection timeout every 10 minutes or so. I want that to stop. I don't have access to the connection string pgadmin uses." I would think that the problem might be related to a router (or firewall) between your pgAdmin client and the PostgreSQL server. This is quite common when you are at home and your router is doing NAT (Network Address Translation). After some idle time (that depends on the settings on the router) the connection is closed by the router.

If this is the case, you have two options:

  1. Change the settings in your router, if that is feasible and you have the proper documentation. Here is an example for Cisco routers.

  2. Change one server parameter, called tcp_keep_alives:

According to the PostgreSQL documentation on Connections:

tcp_keepalives_idle (integer)

Specifies the number of seconds of inactivity after which TCP should send a keepalive message to the client. A value of 0 uses the system default. This parameter is supported only on systems that support the TCP_KEEPIDLE or TCP_KEEPALIVE symbols, and on Windows; on other systems, it must be zero. In sessions connected via a Unix-domain socket, this parameter is ignored and always reads as zero.

The keepalive message should avoid the NAT connection to be dropped.

Keep in mind the remark in the documentation:

This parameter is supported only on systems that support the TCP_KEEPIDLE or TCP_KEEPALIVE symbols, and on Windows

I really don't know which systems "support TCP_KEEPIDLE or TCP_KEEPALIVE symbols", but I guess that Linux and Mac should support them, and so does Windows.

If your system disconnects every 10 minutes, it should be prudent to have this setting to something around 9 * 60 = 540 seconds, or less.

This setting should be in the postgresql.conf on your server. You can also test before making the change in the server, by either using the commands:

SET tcp_keepalives_idle = 480 ;

which would alter the setting for your current connection, or

ALTER role (the-one-you-use) SET tcp_keepalives_idle = 480 ;

which would alter the setting only for this role.


Reference: This video talks about How to Keep Your SSH Sessions Alive. Although this is not exactly the same scenario, it is equivalent (substitute SSH by pgAdmin).

Based on the comment

Pgadmin keeps throwing up a connection timeout every 10 minutes or so. I want that to stop. I don't have access to the connection string pgadmin uses.

I would think that the problem might be related to a router (or, in some cases, a stateful firewall) between your pgAdmin client and the PostgreSQL server. 

This is quite common when you are at home (or in the office) and your router is performing NAT (Network Address Translation). After some idle time the connection is closed by the router. It is not something done by neither pgAdmin nor PostgreSQL, this is something that depends on the settings on the router,

If this is the case, you have three options:

  1. Change the connection_timeout setting in your router, if that is feasible and you have the proper documentation. Here is an example for Cisco routers.

  2. Make the router believe the connection is never idle for long enough. To do that: change one server parameter, called tcp_keep_alives:

According to the PostgreSQL documentation on Connections:

tcp_keepalives_idle (integer)

Specifies the number of seconds of inactivity after which TCP should send a keepalive message to the client. A value of 0 uses the system default. This parameter is supported only on systems that support the TCP_KEEPIDLE or TCP_KEEPALIVE symbols, and on Windows; on other systems, it must be zero. In sessions connected via a Unix-domain socket, this parameter is ignored and always reads as zero.

The keepalive message should avoid the NAT connection to be dropped.

Keep in mind the remark in the documentation:

This parameter is supported only on systems that support the TCP_KEEPIDLE or TCP_KEEPALIVE symbols, and on Windows

I really don't know which systems "support TCP_KEEPIDLE or TCP_KEEPALIVE symbols", but I guess that Linux and Mac should support them, and so does Windows.

If your system disconnects every 10 minutes, it should be prudent to have this setting to something around 9 * 60 = 540 seconds, or less.

This setting should be in the postgresql.conf on your server. You can also test before making the change in the server, by either using the commands:

SET tcp_keepalives_idle = 480 ;

which would alter the setting for your current connection, or

ALTER role (the-one-you-use) SET tcp_keepalives_idle = 480 ;

which would alter the setting only for this role.

  1. Change the keep_alives on the client. You don't need to change any connection_timeout (that parameter is "how long to wait for a connection before deciding that the other side is not responding). Follow the instructions of the accepted answer of Any way to keep connection alive in pgAdmin without setting it on the server?. It's perfectly explained.

Reference: This video talks about How to Keep Your SSH Sessions Alive. Although this is not exactly the same scenario, it is equivalent (substitute SSH by pgAdmin).

1
source | link