I've had as few issues trying to upgrade postgresql-server. I've reverted back to the older version now (9.0.3) and the service is running and accessible via pgadmin/other gui tools.
However, I can't access it via the psql command (as user postgres). This may be possibly because the psql binary seems to be missing. I feel this may have happened when I uninstalled a version of postgres that I had intended to revert to.
I can't reinstall version 9.0.3 because the repo is no longer valid.
Is there any way I can install only the psql binary file and nothing else. I was considering copying the psql binary file from another server, although because the other servers have different versions of postgresql, I'm not sure if this is a good idea (?)
I think psql binaries didn't disapear from your system.
It's just that you had symbolic links from /usr/bin to your 9.0.3 binaries.
When you installed a newer version, this links where replaced to point to the new version and when you uninstalled it, they were dropped.
Try locate to find your binaries. Then you would be able to recreate your symbolic links in /usr/bin.
If you want to try 9.0.3 - you can always build it from source:
https://www.postgresql.org/ftp/source/v9.0.3/
But many distros package pqsl-client seperate from the server and you can use a newer version of psql instead (or at least try).
There are also archives of almost any distro out there and you could fetch that single rpm/deb packge from there.
Related
I'm trying to use VSCode Remote extension to connect to a remote host that runs on RHEL/CentOS 6, but it fails to connect since CentOS 6 ships with GLIBC 2.12 and GLIBCXX 3.4.1. As mentioned in this post, in order to get the extension to work, the workaround is to install GLIBC>=2.17 and GLIBCXX>=3.4.18.
Unfortunately, I don't have sudo access for the server, so I won't be able to update these libraries using the bash script provided in the link. Also, in this SO post, the author says not to update the system GLIBC since it can break down system applications. That being said, I've tried something different -- I extracted those rpm packages, as described in this blog, inside my home folder. I've then updated the env variables PATH and LD_LIBRARY_PATH in ~/.bash_profile to point to these new locations. But the node binary (in VS Code Remote) still can't find these libraries.
Is there a way to let the node binary know where to look for these libraries? More precisely, can someone explain how I can make this extension work without sudo access?
I've got it to work by installing gcc and glibc using Linuxbrew. See this post for more details: https://github.com/microsoft/vscode-remote-release/issues/103#issuecomment-546551293.
Couple of things to take note of:
Node binary versions in VS Code Server may vary between commits. In the GitHub comment above, the author uses node#10 -- you may replace it with node#12; everything would still work.
Make sure glibc and gcc are properly installed using linuxbrew. This step is key.
The Linux machine I use has SuSE 12.1 with Postgres 9.4 installed (as root). I was able to compile and install the PostGIS 2.5 extension in a user area. Under this installation, I see, among other things, contrib folder, some sql files and .so files etc.
I can launch Postgres using my personal user. How can I let Postgres know to refer to this directory where all the PostGIS extension related files/objects are available?
When I try creating the extension, I get the following error:
ERROR: could not open extension control file "/usr/share/postgresql94/extension/postgis.control": No such file or directory
Of course, some error is expected as Postgres doesn't know about my PostGIS installation. But the latter does not have such a file, postgis.control.
I am guessing the solution is to ensure Postgres can see the .so files (may be set LD_LIBRARY_PATH?) or create a postgis.control file with all the relevant details etc.
Any assistance including simply pointing to documentation will be appreciated.
I see a few similar questions but no one seems to address my issue of the extension - PostGIS - in a separate directory. They assume root access.
Like every extension, PostGIS has to be installed in the PostgreSQL extension subdirectory (under share).
When PostGIS is configured, it looks for pg_config on the PATH, or you can explicitly specify the --with-pgconfig option to configure.
Once you have built PostGIS, make install will automatically put all files in the proper place.
You are not very specific how you built PostGIS, but you must have strayed from the correct path somewhere. If you share some details, we might be able to figure out what went wrong.
Re-reading your question I get the impression that you installed PostGIS somewhere outside the PostgreSQL software directory because you lack the necessary root privilege. That simply won't work, and there is no workaround.
You'd have to install PostgreSQL somewhere where you have write access.
I uninstalled my PostgreSQL because I'm trying to use version 9.1.9. I tried reinstalling it. It successfully installed from what I can see.
However, when typing in psql --version on the command line, I get that it is still using version 9.0.10
How can I make it use the new version?
psql is the command line interface and its version can be independent of the Postgres server.
To get the version of the server software run SELECT version() against the database you are connected to (from within psql). Though it is possible to interact with different versions, some obvious limitations apply. I suggest you uninstall the outdated psql as well and use the version matching the server.
If you're running this on a UNIX/Linux system the problem is likely to do with where psql is being called from. It doesn't sound like the old version got removed and you're still calling it when you run psql. Try running this:
which psql
That will tell you the full path of what gets invoked when you run just psql. To see if there are other instances of psql installed on your system try running:
sudo updatedb
(you'll need to put in your password here). And then:
locate psql
Your system likely uses some kind of package manager, which controls which packages are installed. For example, Ubuntu/Debian use dpkg, Redhat uses yum, you may be using something like fink or macports if you are using OSX.
I will keep it short for the people who don't want to read too much. Currently, I am trying to run PostgreSQL.app 9.3.0. (Homebrew didn't work and complained that there might be conflicting versions).
It seems to run pretty well, however my psql's version is 9.1.0 and it causes some problems. Psql is probably a left over from another installation/uninstallation maybe a year ago.
Is there a way to update psql or locate it so that I can re-install it. Maybe these two screenshots maybe will give you an idea.
Thank you!
http://i.imgur.com/u3H4hxJ.png
http://i.imgur.com/DaBnzTi.png
Use the 'which' command in the terminal to determine the path/location of the command in question. For example:
$ which psql
/Library/PostgreSQL/9.3/bin/psql
The first image you posted is likely a result of running the psql that comes with default OS X installs. That version is located at:
/usr/bin/psql
I wouldn't recommend removing it however. Instead, once you've installed a version of psql that matches your server (or perhaps it's already there but is just behind the other version in your path), update your path so that the proper psql command comes before the default OS X one and any others. If you are using bash as your preferred shell, for example, then put this in your ~/.bash_profile file:
# add PostgreSQL binaries to the path
export PATH=/Library/PostgreSQL/9.3/bin:$PATH
Are there conflicts created if Firebird is installed to a system that already has Interbase installed. I see some mention of using the same Ports, additions to the Path, and a common program name in ISQL.exe as the command processor. I see references to FB version 1.5 documentation to resolve these, is there more updated information? Has this not been changed in current releases? If Firebird (current version) is simply installed, will Interbase installations then have problems and need work to get them working again?
1.You need to modify the port section for firebird in the conf so each will have a different port
2.when you asked about if to copy the legacy gds32 dll you need to uncheck it for firebird install setup so it will install only in it's own folder and not on the system
http://ibexpert.net/ibe/uploads/Doc/dmiles469.gif
The ISQL.exe issue can be solved in command line with modified PATH so you can add there the Firebird install path