I've installed Postgresql 9.4 on a windows server 2008. I am writing an application that will access this server from our Windows 7 machines. I also installed PGAdminIII on one workstation where I am developing.
I am not able to connect from the workstations. I get a "Server doesn't listen" message. I've looked online for some solutions but none seemed to help me.
On the Server where the service is running. I've tried and change the values through paAdminIII for the files pg_hba.conf and
It looks like pg_hba.conf was setup to listen to the loopback and then a range of ip addresses on the same computer. When I change the "host" key value of the ip_address range from 127.0.0.1/32 to 192.168.2.1/128 (and keep the other values the same -> all, all, md5) the service starts and then stop immediately.
If I leave it with 127.0.0.1/32 then it starts fine but I can not connect from the workstation.
I left the listen_addresses on the postgresql.conf file as the default "*" which is trying to listen to all addresses.
I am trying to develop a client/server app before moving it to the cloud and this is step 0.
I did install on my Windows 7 machine an "add_on" the VisualStudio to help me get a connect string down the line but I am only using the PostgreSql "tools" at this time.
I did some search to see if this question was asked before in this client/server scenario and did not find one. If it has already been answered I'd appreciate some pointers directing me to the correct way to configure server access, if not, then an answer on how to do it would be great.
I can ping the server with no problems from the workstation(s).
The IP address/CIDR mask specification of 192.168.2.1/128 is wrong. The last value indicates the number of bits to be masked, not an IP address range. If you want (most of) the range 192.168.2.1 - 192.168.2.128, the entry in pg_hba.conf should be 192.168.2.0/25 (meaning: take the three highest bytes 192.128.2 (24 bits), plus the highest order bit 0 of the last byte and let the 7 remaining bits vary (values 0 to 127).
Note that this includes 192.168.2.0 and excludes 192.168.2.128, but that is just how bit masking of IP addresses works. You could add 192.168.2.128 with a separate entry in pg_hba.conf, but you cannot get 192.168.2.0 out.
Related
Running the top-command top -c on an Ubuntu server shows all the commands that are currently running. Concerning PostgreSQL commands, what do the values in the brackets mean? I am speaking of the values right next to the red box in the picture.
I can not find any documentation to support this, but I believe it is the client's remote port.
The PostgreSQL server is listening on a specific port (5432 by default) and when a client contacts it via TCP the client provides an arbitrary port for the server to talk back to the client. The red box in your example is covering the IP address of the client, that along with the port plus the IP:Port of the server makes up the unique connection.
I have a number of identical local postgreSql databases (identical in structure - not data) on several laptops that have intermittant access to internet. Records are being added to each DB daily. So Branch A,B,C each with a local Postgresql database. I would like all records from A,B,C in each table in a cloud Database.Also A,B,C data is separate - there is no overlap - A doesnt change B, or C etc. There are no duplicated unique keys.
NEED: I would like to collect all this data on a cloud based database by adding daily incremental data to a single cloud databse - so I can query the whole consolidated data using SQL and pull reports as needed.
Please can anyone point me in the right direction?
Thanks
It sounds like you want logical replication from each laptop to the cloud server. The problem there might be that contact must be made by the replica to each of the masters, so when your laptops are online, they would need to have predictable IP addresses so that they can be reached.
Maybe the best way around this is with a reverse SSH tunnel. On the central replica, you would tell it to subscribe to a publication hosted on some non-standard port on localhost. With a different port reserved for each laptop. So, for example, 9997, 9998, and 9999.
Then when each laptop has connectivity, it could run something like:
ssh rajb#1centralserver.example.com -R9999:localhost:5432 -f -N -T
This establishes an ssh connection to the central server (requiring a password, or private key, or however you have ssh set up) and sends instructions to the central server that whenever someone connects to port 9999 on the central server it should really send that connection back over ssh tunnel and hook it up to port 5432 (the default postgres server port) of the laptop.
For initially setting things up and debugging, you might want to omit the -f -N -T. That way, in addition to setting up the tunnel, you also get an interactive ssh session you can use for monitoring things.
Once the central service notices the connection is available, it will start downloading changes since the last time it could connect. When there is no connection, you will get a lot of nuisance messages to the log file as it checks each server every ~5 seconds to see if it is available.
From each laptop's perspective, the connection is coming from within, so the replication connection will use whatever authentication is set up or 127.0.0.1 or ::1, not the authentication set up for the actual remote IP.
I wrote a script that goes through all local IPs in the '0' network (192.168.0.*).
I use a loop with socket.gethostbyaddr(ip_modified_by_the_loop_each_time).
The loop returns me 3 devices their hostnames.
Now, I found that it does not find 4 devices (at least).
It does wind my Windows Laptop, not my Android Phone. It does find
one MacBook, not the iMac, not the other MacBook. It also does not
find any phone.
I know that all the devices are online and have an IPv4 address.
I can ping them very well, it responds just fine. But when I use socket.gethostbyaddr(ip_modified_by_the_loop_each_time) it throws an error.
I used a try:/except: statement to get around the error, but it still can not find my phone by IP and get the hostname, but I know it is there.
I am using python 3.3
Why is that happening, how to fix that?
Thank you.
gethostbyaddr tries to find out the hostname for a given IP address by using either locally stored information (i.e. /etc/hosts) or doing a reverse DNS lookup. The result does not depend on the host being online or not, they only depend on the availability of these information.
And these information can also not be trusted. For example the DNS operator of a domain could add the following records:
test.example.com A public.ip.of.test
public.ip.of.test PTR localhost.
In this case a lookup (gethostbyname) of test.example.com would return the IP address of this host while a reverse lookup (gethostbyaddr) would claim that the hostname is localhost. And if the PTR record would be missing gethostbyaddr would fail, even if the host is online.
See also wikipedia: reverse dns lookup.
I'm having a rather annoying problem with my home setup where I have two computers, a table PC and a laptop, connected in a home network. I have installed a WAMP server on my laptop to act as a server and the laptop is now running Windows 10. I noticed a significant drop in speed lately and pinpointed the problem being IPV6 in the laptop resulting in localhost/phpmyadmin being very slow taking one table 30 seconds to load slowing down my work.
When I still had Windows 8 I disabled the IPV6 connection by inserting a registery DWORD DisabledComponents into Windows Registry, but now that I have Windows 10 and after attempting to reconnect to home group the system prompted me to re-activate IPV6.
Now is there any way to speed up WAMP with IPV6? This is beginning to be a problem as IPV6 is starting to be used by some web addresses (like Google) of course having IPV4 too but still.
Your percieved speed issues could be due to so many things from just not enough muscle in the laptop to run a webserver + Database Server + PHP + etc etc, its impossible to guess a good answer.
However it might be worth doing some optimisation before throwing the IPV6 baby out with the bath water!
First, in W10 Microsoft seemed to think it was a good idea to install IIS by default. If you are not using it, you can quite happily remove it.
It often makes connections to MySQL run quicker if you use 127.0.0.1 instead of localhost as the host, although this is now the default in the WAMPServer's phpMyAdmin configuration, its worth checking to see you have not chnaged it back to localhost for some reason.
In later versions of MySQL they changed a default value that can make the table_definition_cache hog large amounts of memory, as much as half a gig.
I have found I can reduce the memory footprint of a resting MySQL server by adding this parameter to the my.ini with a more sensible default like so without causing any obvious detremental effects to MYSQL's performance.
table_definition_cache = 600
Using this can free up 3 to 4 hundered meg of memory that was probably not being used, especially as the default database engine is now INNODB anyway.
If you are reloading large database backups etc, its probably quicker to use the mysql.exe command line processor than phpMyAdmin.
left click wampmnager -> MySQL -> MySQL console
Then use the source command from the mysql command prompt i.e.
mysql > source '/path/to/file.sql';
Here's what I've done:
I wrote a minimal web server (using Qt, but I don't think it's relevant here).
I'm running it on a legal Windows 7 32-bit.
The problem:
If I make a request with Firefox, IE, Chrome or Safari it takes takes about one second before my server sees that there is a new connection to be accepted.
Clues:
Using other clients (wget, own test client that just opens a socket) than Firefox, IE, Chrome, Safari seeing the new connection is matter of milliseconds.
I installed Apache and tried the clients mentioned above. Serving the request takes ~50ms as expected.
The problem isn't reproducible when running Windows XP (or compiling and running the same code under Linux)
The problem seems to present itself only when connecting to localhost. A friend connected over the Internet and serving the connection was a matter of milliseconds.
Running the server in different ports has no effect on the 1 second latency
Here's what I've tried without luck:
Stopped the Windows Defender service
Stopped the Windows Firewall service
Any ideas? Is this some clever 'security feature' in Windows 7? Why isn't Apache affected? Why are only the browsers affected?
If you're saying "localhost" instead of "127.0.0.1", you're forcing a name lookup before the actual connection attempt, adding delay.
In addition, some browsers, like Firefox 3.5+, don't use the operating system's DNS lookup mechanism, which is why it can have different performance than, say, wget.
You may be running into some automatic proxy discovery problem. In Firefox, you can disable this in Options | Advanced | Network | Settings; select either "No proxy" or give it explicit values. There's also the Internet Properties control panel, which is IE's network settings, but other browsers on Windows may obey settings here, too. Again, disable auto-proxy discovery. This can speed connections outside localhost, too.
For some reason Windows 7 takes 1 second to resolve address localhost regardless of it being in hosts file.
Adding localhost1 to hosts file and using that works around the problem.
When connecting to localhost on a IPv4/IPv6 dual stack host:
A DNS lookup is performed for localhost.
The DNS server (whether IPv6 enabled or not - this doesn't matter) returns both the AAAA record ::1, and the A record 127.0.0.1.
The client first attempts to connect to ::1.
We assume your server program is not IPv6-capable, which is a common case - due to historical reasons, many servers bind their socket to 0.0.0.0 by default rather than [::].
Here an ECONNREFUSED error would be raised for the client. This happens immediately on most platforms; on Windows however, a single call to connect() would try 3 times in 500ms intervals before giving up, hence taking a bit more than one second (See http://stackoverflow.com/q/19440364 for more details).
The client then creates a connection to 127.0.0.1 instead.
This would explain all your clues above:
If you make a request with Firefox, IE, Chrome, Safari or any other IPv6-capable clients, it takes takes about one second trying for ::1 before connecting to 127.0.0.1.
Your own test client just opens a INET socket, so it won't try ::1 at all.
Using a dual-stack server such as Apache, the clients will connect to ::1 happily.
The problem isn't reproducible on Windows XP, of which IPv6 support is not enabled by default.
The problem seems to present itself only when connecting to localhost, as your friend connected with an IPv4-only network.
Running the server in different ports has no effect on the 1 second latency.