So, i have a database that i've already imported to Postgresql in multiple ways, using either the command line or pgadmin3 directly, but all attempts give me the same problem: i can't query anything when using a simple script such as
select max(velocity) from taxidatabase
because i am greeted with "relation does not exist".
I've already searched high and low and i noticed that error is caused by conflicts in name of databases that use capital letters and such, but you can see i shouldn't have that problem, as i've used nothing than small letters.
So i'm totally lost on what to do. And yes, i'm really still learning the ropes in postgresql so if it is just something really basic like an option i'm missing, pardon me! This image shows the error i'm getting and some more info you might need.
I'm using a virtual machine with
VMware Workstation
Ubuntu 15.04
Postgresql 9.4
pgAdmin3 v1.20
Thanks in advance!
Related
I have this client where we installed a PGSQL server on his server (PGSQL 13 on port 5432)
There already was a postgresql server installed (8.3, port 15432).
No problems here.
Our application has a few 'bytea' columns where we store some encrypted data. Strange things happen when I launch a SQL on this column.
Exactly the same code gives different results on different computer.
For example: "Select ByteAColumn from RandomTable"
Results on my computer:
"E712F7671E929600C926003C61C4C696C27E89C8D836F85898737799DFAB1CC4"
Result on server where the Postgresql is installed:
"\x45373132463736373145393239363030433932363030334336314334433639364332374538394338443833364638353839383733373739394446414231434334"
Result on other computer in the network of the client:
"E712F7671E929600C926003C61C4C696C27E89C8D836F85898737799DFAB1CC4"
Result on "Select ByteAColumn::varchar from RandomTable" in PGAdmin 4:
\x45373132463736373145393239363030433932363030334336314334433639364332374538394338443833364638353839383733373739394446414231434334
My application expects the "E712F7671E929600C926003C61C4C696C27E89C8D836F85898737799DFAB1CC4" one and throws error on the result with '\x4...'.
I can avoid this using "Select encode(ByteAColumn,'escape') from RandomTable", this gives the right results. Modifying our entire application is near impossible.
In other words: the application runs fine on my computer, works fine on client computers / terminal server but not on the server where the postgreSQL database is hosted.
I've been using this application for over a year now. I have done many installations of this application and never have had this issue before. I've tested the query on other installations where everything is fine, and there I also get the '\x45...' result, but using the query in my application works great.
What causes this?
Is it the PostgreSQL 8.3 server which interferes somehow? I've been testing and searching a whole day now and I can't seem to find the answer.
Help would be greatly appreciated.
Thanks!
I'm finding references in the 9.5 manual to phraseto_tsquery
https://postgrespro.com/docs/postgrespro/9.5/textsearch-controls
But if I use it in my query it gives me this error:
No function matches the given name and argument types.
SELECT phraseto_tsquery('english', 'The Fat Rats');
Was this function not added with 9.5 as intended or is it likely there's some other problem on my side. Running 9.5.4 of the database currently. Anyone that can confirm?
For anyone looking; took the step to install postgresql 9.6beta4 and I'm no longer receiving the error message. In other words phraseto_tsquery seems to only be fully supporting in the current 9.6 beta and upcoming full release.
I am using pgProvider on a MVC3 Mono application and had no issues on Windows Postgres 9.2. I am migrating to my production Linux/Mono environment, and received an error when attempting to access the provider:
"42704: language "plpgsql" does not exist"
I am using postgreSQL 8.4 on CentOS 6.3
I looked at some info, and ran the following:
createlang -d dbname plpgsql
When I run it again, it affirms that the database is already there.
I restarted postgresql and my app. However, I still get the above error.
Does anyone have any info on why I would still receive an "plpgsql does not exist -- after it is installed?"
In general this sort of error is an indication that something is not as you expect and you need to challenge your assumptions.
Please note that languages do not require restarting the database server to take effect on any version of PostgreSQL. Also note that what languages are allowed in PostgreSQL is a per-db catalog entry (languages, unlike users and roles, are not cluster-global).
So in troubleshooting this, you need to start with:
Is this the right db? The right server?
Is my application connecting to the same db/server I think it is?
Given that createlang affirms that the language exists after you run it, this can't be an issue with PostgreSQL raising a phony error. Instead it must be a problem with the changes you made not affecting the database your application is using.
I get this exception in PostgreSQL:
org.postgresql.util.PSQLException: ERROR: could not access file "$libdir/plpgsql": No such file or directory
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1721)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1489)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:193)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:337)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:236)
at org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:205)
I searched a lot and most solution points to a wrong installation. But this is my test db which has been running without issues for a long time. Also inserts are working. Issue occurs only on select queries.
Apparently, you moved your PostgreSQL lib directory out of place. To confirm this, try the following in psql:
> SET client_encoding TO iso88591;
ERROR: could not access file "$libdir/utf8_and_iso8859_1": No such file or directory
If you get an error message like this, then my theory is correct. You'll need to find out where those files ended up, or you can reinstall PostgreSQL to restore them.
To find out what $libdir is referring to, run the following command:
pg_config --pkglibdir
For me, this produces:
/usr/lib/postgresql
I have the same problem: the other postgres server instance (8.4) was interfering with the 9.1 one; when the 8.4 instance is removed it works.
the other instance can sometimes be removed from the system while still running (e.g. you do a gentoo update and a depclean without stopping and migrating your data). so the error seems particularly mysterious.
the solution is usually going to be doing a slot install/eselect of the old version (in gentoo terms, or simply downgrading on other distros), running its pg_dumpall, and then uninstalling/reinstalling the new version and importing the data.
this worked pretty painlessly for me
I installed MongoDB both on Win 7 and on Mac OS X, and both places, I got mongod (the server) and mongo (the client).
But at both places, running mongod will fail if I double click on the file, and the error message was gone too quickly before I can see anything. (was better on Mac because Terminal didn't exit automatically and showed the error message).
Turned out it was due to /data/db not exist and the QuickStart guide says: By default MongoDB will store data in /data/db, but it won't automatically create that directory
I just have a big question that MongoDB seems to want a lot of people using it (as do many other products), but why would it not automatically create the folder for you? If it didn't exist... creating it can do not much harm... especially you can state so in the user agreement. The question is why. I can think of one strange reason, but the reason may be too strange to list here...
One good reason would be that you do not want it in /data/db. In this case, you want it to fail with an error when you forgot to specify the correct directory on the command line. The same goes for mis-spelled directory names. If MongoDB just created a new directory and started to serve from there, that would not be very helpful. It would be quite confusing, because databases and collections are auto-created, so there would not even be errors when you try to access them.