When connecting to a pg 11 instance and executing
select setting, source from pg_settings
where name='tcp_keepalives_interval';
I get two different responses between connecting via psql and a script with using Npgsql;
The command line psql client returns
0 | default
while the Npgsql script will return
75 | default
75 matches net.ipv4.tcp_keepalive_intvl but I still would have expected 0.
What is the cause of this discrepancy and how can I account for it generally in C# with Npgsql?
Looking into my crystal ball, I see that your database server is not on Windows and the psql session is running on the database server. Your psql session is connected via UNIX sockets (a local connection).
The documentation says (emphasis mine):
keepalives_count
Controls the number of TCP keepalives that can be lost before the client's connection to the server is considered dead. A value of zero uses the system default. This parameter is ignored for connections made via a Unix-domain socket, or if keepalives are disabled. It is only supported on systems where TCP_KEEPCNT or an equivalent socket option is available; on other systems, it has no effect.
If you connect with psql via TCP, you should see 75 as well.
Related
I have tried to connect to a DB2 DB using the command line:
schemacrawler --server=db2 --host=*myhost* --port=*myport* --database=*db2database* --user=*myuser* --password=*mypassword* --info-level=minimum --command=list --log-level=CONFIG
I get the following error:
SchemaCrawler 16.11.7
Error: Could not connect to
jdbc:db2://pathtodb:retrieveMessagesFromServerOnGetMessage=true;, for
user 'user', with properties {}: [jcc][t4][2043][11550][4.28.11]
Exception java.net.ConnectException: Error opening socket to server
myserver on port myport with message: Connection timed out: connect. ERRORCODE=-4499, SQLSTATE=08001
I have the suspicion that there is a problem in the company's firewall that does not let me connect from SchemaCrawler. I can connect to the db with DBeaver from a virtual machine (Saas). Since DBeaver is running SaaS I do not have access to the VM and cannot test from there.
How could I check if the network is blocking SchemaCrawler requests from my local machine (Windows 10 Enterprise 1909)?
Windows-10 includes ping and tracert and nslookup tools (you run these in a CMD window). These ping and tracert may help you determine if there is IP-level connectivity between your Win10 box and the target Db2-server. Refer to any good textbook to learn how to use these tools.
Windows-10 also has its own software-firewall ( run from the start box if you search firewall) which needs you to add a rule to open the relevant port for tcp and udp traffic. Your login may need to have suitable permissions to make changes like this, so in some corporate environments access is restricted. If this is the case, open a ticket with relevant support teams, as that is not a matter for StackOverflow.
If adding such a rule does not fix your symptom, then you should contact the network support people in your company to open the relevant ports or provide another means for you to achieve the goal.
Note also that there are other tools (arguably better tools) to get a DDL report for a Db2 database, including the db2look utility which is present in the Db2 fat client, and also present on Db2-LUW servers. If the Db2-server runs on either i-series or Z/OS then other tools exist for those environments so talk with the relevant administrators.
I am installing DSPACE which needs PostgresSQL.
Please see this link: DSPACE INSTALL
It says:
Then tighten up security a bit by editing pg_hba.conf and adding this line:
host dspace dspace 127.0.0.1 255.255.255.255 md5.
I have read on the internet as to how the above line works. It needs a connection type followed by database name/user name followed by IP address and the authentication scheme.
My question is: Should this not be a local (in place of host) connection since the dspace user is running locally?
Can someone show me step by step as to what happens when a request comes in?
Where are the instructions that the dspace user will submit a request using md5?
DSpace uses JDBC, so local won't work for it. Here local means a completely different kind of inter-process connection that has nothing to do with IP and can only address local processes: Unix sockets. JDBC uses only IP, so DSpace needs a host descriptor.
That period at the end of the line is not supposed to be part of it. The documentation was unclear there -- I've fixed it.
As Laurenz Albe noted, DSpace doesn't specify that MD5 password hashes be used. The PostgreSQL server controls which methods will be tried, based on what you specify in pg_hba.conf.
First, there is a . at the end of your pg_hba.conf line. That is a syntax error.
Whether to use local or host depends on
what API this DSPACE is using (JDBC, for example, allows no UNIX socket connections)
what connection string DSPACE is using
If you can specify a socket directory as host name, you can probably use UNIX sockets, which would be more efficient.
If DSPACE uses a driver that supports md5 authentication, the procedure is like this:
client sends server a connect packet with user and database
server requests md5 authentication and sends a random "salt" string
client computes an MD5 hash of the password with the salt from the server and sends the result to the server
server verifies that the hash is correct
I'm setting up a server, with postgresql running as a service. I can use nmap to get current postgresql version
nmap -p 5432 -sV [IP]
It returns:
PORT STATE SERVICE VERSION
5432/tcp open postgresql PostgreSQL DB 9.3.1
Is there a way to hide the postgresql version from nmap scanning? I've searched but it's all about hiding the OS detection.
Thank you.
There's only one answer here: Firewall it.
If you have your Postgres port open, you will be probed. If you can be probed, your service can be disrupted. Most databases are not intended to be open like this to public, they're not hardened against denial-of-service attacks.
Maintain a very narrow white-list of IPs that are allowed to connect to it, and whenever possible use a VPN or an SSH tunnel to connect to Postgres instead of doing it directly. This has the additional advantage of encrypting all your traffic that would otherwise be plain-text.
You have a few options, but first understand how Nmap does it: PostgreSQL database server responds to a malformed handshake with an error message containing the line number in the source code where the error occurred. Nmap has a list of possible PostgreSQL versions and the line number where the error happens in that particular version. The source file in question changes frequently enough that Nmap can usually tell the exact version in use, or at least a range of 2 or 3 version numbers.
So what options do you have?
Do nothing. Why does it matter if someone can tell what version of PostgreSQL you are running? Keep it up to date and implement proper security controls elsewhere and you have nothing to worry about.
Restrict access. Use a firewall to limit access to the database system to only trusted hosts. Configure PostgreSQL to listen only on localhost if network communication is not required. Isolate the system so that unauthorized users can't even talk to it.
Patch the source and rebuild. Change PostgreSQL so that it does not return the source line where the error happened. Or just add a few hundred blank lines to the top of postmaster.c so Nmap's standard fingerprints can't match. But realize you'll have to do this every time there's a new version or security patch.
I am using pgAdmin to connect remotely to my database as phpPgAdmin is a bit limited in its features. Only problem is if I leave the SQL window open without running a query for a few minutes, then it says I need to reconnect.
Is this a setting I need to change in my database to keep remote connections alive for longer or is it a pgAdmin setting?
It is client setting.
You need specify connect_timeout in your config file.
29.1. Database Connection Control Functions
29.14. The Connection Service File
I have an app running on Heroku. This app has an Postgres 9.2.4 (Dev) addon installed. To access my online database I use Navicat Postgres. Sometimes Navicat doesn't cleanly close connections it sets up with the Postgres database. The result is that after a while there are 20+ open connections to the Postgres database. My Postgres installs only allows 20 simultanious connections. So with the 20+ open connections my Postgress database is now unreachable (too many connections).
I know this is a problem of Navicat and I'm trying to solve this on that end. But if it happens (that there are too many connections), how can I solve this (e.g. close all connections).
I've tried all of the following things, without result.
Closed Navicat & restarted my computer (OS X 10.9)
Restarted my Heroku application (heroku restart)
Tried to restart the online database, but I found out there is no option to do this
Manually closed all connections from OS X to the IP of the Postgres server
Restarted our router
I think it's obvious there are some 'dead' connections at the Postgres side. But how do I close them?
Maybe have a look at what heroku pg:kill can do for you? https://devcenter.heroku.com/articles/heroku-postgresql#pg-ps-pg-kill-pg-killall
heroku pg:killall will kill all open connections, but that may be a blunt instrument for your needs.
Interestingly, you can actually kill specific connections using heroku's dataclips.
To get a detailed list of connections, you can query via dataclips:
SELECT * FROM pg_stat_activity;
In some cases, you may want to kill all connections associated with an IP address (your laptop or in my case, a server that was now destroyed).
You can see how many connections belong to each client IP using:
SELECT client_addr, count(*)
FROM pg_stat_activity
WHERE client_addr is not null
AND client_addr <> (select client_addr from pg_stat_activity where pid=pg_backend_Tid())
GROUP BY client_addr;
which will list the number of connections per IP excluding the IP that dataclips itself uses.
To actually kill the connections, you pass their "pid" to pg_terminate_backend(). In the simple case:
SELECT pg_terminate_backend(1234)
where 1234 is the offending PID you found in pg_stat_activity.
In my case, I wanted to kill all connections associated with a (now dead) server, so I used:
SELECT pg_terminate_backend(pid), host(client_addr)
FROM pg_stat_activity
WHERE host(client_addr) = 'IP HERE'
1). First login into Heroku with your correct id (in case you have multiple accounts) using heroku login.
2). Then, run heroku apps to get a list of your apps and copy the name of the one which is having the PostgreSQL db installed.
3). Finally, run heroku pg:killall --app appname to get all the connections terminated.
From the Heroku documentation (emphasis is mine):
FATAL: too many connections for role
FATAL: too many connections for role "[role name]"
This occurs on Starter Tier (dev and basic) plans, which have a max connection limit of 20 per user. To resolve this error, close some connections to your database by stopping background workers, reducing the number of dynos, or restarting your application in case it has created connection leaks over time. A discussion on handling connections in a Rails application can be found here.
Because Heroku does not provide superuser access your options are rather limited to the above.
Restart server
heroku restart --app <app_name>
It will close all connection and restart.
As the superuser (eg. "postgres"), you can kill every session but your current one with a query like this:
select pg_cancel_backend(pid)
from pg_stat_activity
where pid <> pg_backend_pid();
If they do not go away, you might have to use a stronger "kill", but certainly test with pg_cancel_backend() first.
select pg_terminate_backend(pid)
from pg_stat_activity
where pid <> pg_backend_pid();